Home » Modeling » EMF » [Xcore] multi-level class hierarchy extension
| [Xcore] multi-level class hierarchy extension [message #1093251] |
Fri, 23 August 2013 20:31  |
Eclipse User |
|
|
|
Greetings!
I'm trying to create a two-level xcore class hierarchy, maintaining all
hand-written code under src/, while preserving src-gen/ as the default
generated source output dir to avoid code merge overhead upon code
generation. The problem is I am unable to control the generated class
hierarchy as much as I need, specifically, I'm unable to override the
extend target of the generated subclass, to have it point my src/ located
extension class.
Basically what I have is this:
xcore model:
package main
class A {}
class B extends A {}
sought code layout:
├── src
│ └── main.impl
│ ├── BImplExt.java
│ └── AImplExt.java
└── src-gen
└── main
├── B.java
├── A.java
└── impl
├── BImpl.java
└── AImpl.java
where BImplExt, AImplExt extends BImpl, AImpl respectfully. How may I set
main.impl.BImpl to extend main.impl.AImplExt? '@generated not' is not an
option under src-gen/... I've also tried to have B wrap AImplExt:
class B wraps main.AImplExt {}
but this generates BImpl as if AImplExt were an interface... any hint?
|
|
|
| Re: [Xcore] multi-level class hierarchy extension [message #1093476 is a reply to message #1093251] |
Sat, 24 August 2013 05:28  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Amir,
The Xtext folks have specialized the code generator to support such a
pattern (in their MWE-based generator) but there's no direct support for
that in EMF.
What kind of code are you putting into your *Ext.java classes (and why
can't it be expressed in Xcore itself)?
On 23/08/2013 10:31 PM, Amir Sagie wrote:
> Greetings!
>
> I'm trying to create a two-level xcore class hierarchy, maintaining all
> hand-written code under src/, while preserving src-gen/ as the default
> generated source output dir to avoid code merge overhead upon code
> generation. The problem is I am unable to control the generated class
> hierarchy as much as I need, specifically, I'm unable to override the
> extend target of the generated subclass, to have it point my src/ located
> extension class.
>
> Basically what I have is this:
>
> xcore model:
>
> package main
>
> class A {}
> class B extends A {}
>
>
> sought code layout:
>
> ├── src
> │ └── main.impl
> │ ├── BImplExt.java
> │ └── AImplExt.java
> └── src-gen
> └── main
> ├── B.java
> ├── A.java
> └── impl
> ├── BImpl.java
> └── AImpl.java
>
> where BImplExt, AImplExt extends BImpl, AImpl respectfully. How may I set
> main.impl.BImpl to extend main.impl.AImplExt? '@generated not' is not an
> option under src-gen/... I've also tried to have B wrap AImplExt:
>
> class B wraps main.AImplExt {}
>
> but this generates BImpl as if AImplExt were an interface... any hint?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Xcore] multi-level class hierarchy extension [message #1093854 is a reply to message #1093476] |
Sat, 24 August 2013 19:49 |
| Eclipse User |
|
|
|
> The Xtext folks have specialized the code generator to support such a
> pattern (in their MWE-based generator) but there's no direct support for
> that in EMF.
>
> What kind of code are you putting into your *Ext.java classes (and why
> can't it be expressed in Xcore itself)?
Personally I prefer to host implementation code exclusively in .java
files. In my specific case both classes share some low level, time
related logic which can gain little from the xbase expression language -
hosting such code in what is currently one monolithic xcore model would
feel a bit out of place...
I was wondering though what it would take to support wrapping around
concrete EObject types, as attempted in the previous example:
class B wraps main.AImplExt
I suppose the xcore generator would first need to realize this is class
rather than an interface, then attempt to walk up the class hierarchy to
assert it eventually reaches it's original super type candidate
(MinimalEObjectImpl.Container, or whatever the root extends class is for
that matter), and if so use the wrapped type as the super class target.
Is there any interest to support such a feature?
|
|
|
| Re: [Xcore] multi-level class hierarchy extension [message #1094101 is a reply to message #1093854] |
Sun, 25 August 2013 05:22 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Amir,
On 24/08/2013 9:49 PM, Amir Sagie wrote:
>> The Xtext folks have specialized the code generator to support such a
>> pattern (in their MWE-based generator) but there's no direct support for
>> that in EMF.
>>
>> What kind of code are you putting into your *Ext.java classes (and why
>> can't it be expressed in Xcore itself)?
> Personally I prefer to host implementation code exclusively in .java
> files. In my specific case both classes share some low level, time
> related logic which can gain little from the xbase expression language -
It also loses little...
> hosting such code in what is currently one monolithic xcore model would
> feel a bit out of place...
Yes, eventually I'll need to think about how to evolve Xcore so that one
could split from the same logical package across multiple resources.
>
> I was wondering though what it would take to support wrapping around
> concrete EObject types, as attempted in the previous example:
>
> class B wraps main.AImplExt
That's already supported but doesn't mean what you intend. Ecore does
not model implementation classes directly, it models the API. What
you're asking for is a different code generation pattern.
>
> I suppose the xcore generator would first need to realize this is class
> rather than an interface,
You have to keep in mind that Xcore is just syntactic sugar. Everything
has to map back onto an Ecore/GenModel pair and from that the normal
code generation takes place; even the Xbase block expressions are mapped
to annotations...
> then attempt to walk up the class hierarchy to
> assert it eventually reaches it's original super type candidate
> (MinimalEObjectImpl.Container, or whatever the root extends class is for
> that matter), and if so use the wrapped type as the super class target.
>
> Is there any interest to support such a feature?
Yes, I would consider adding flexibility to the generator for the
"generation gap" pattern the Xtext folks are using. A relatively simple
approach is to define the source folder for your hand written
implementation classes and have the generator inspect that folder at
generation time. I.e., when generating a reference to
org.example.foo.impl.BarImpl.java look to see if there is an
org.example.foo.impl.BarImplCustom.java in that source folder and then
use that instead of just BarImpl. Of course the generated factory needs
to refer to those custom impls as well, not just other derived
implementation classes... The Xtext guys achieve their "generation cap"
results effectively just by specializing the import manager using this
approach...
So feel free to open a bugzilla enhancement request.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [Xcore] multi-level class hierarchy extension [message #1094496 is a reply to message #1094101] |
Sun, 25 August 2013 20:31 |
| Eclipse User |
|
|
|
Thanks for the prompt feedback, comments below.
> Yes, eventually I'll need to think about how to evolve Xcore so that one
> could split from the same logical package across multiple resources.
Why not build a xcore macro language? just kidding... ;] I'd be happy to
use this to refactor type definitions out to a separate resource. A non
circular include mechanism would work, and as a way to defer the decision
which URL types would be supported (platform://, file:// namespace, etc)
we could start by only supporting local root-model relative file
references.
That being said I think this would have to depend on the xcore editor
being able to present the fully expanded model, in the same way the ecore
editor allows you to drill down any loaded resource.
>> I was wondering though what it would take to support wrapping around
>> concrete EObject types, as attempted in the previous example:
>>
>> class B wraps main.AImplExt
> That's already supported but doesn't mean what you intend. Ecore does
> not model implementation classes directly, it models the API. What
> you're asking for is a different code generation pattern.
Well, this could be interpreted as sugar for 'extend all interfaces
directly implemented by AImplExt', or perhaps a 'instance type name'
annotation of some sort.
>> Is there any interest to support such a feature?
> Yes, I would consider adding flexibility to the generator for the
> "generation gap" pattern the Xtext folks are using. A relatively simple
> approach is to define the source folder for your hand written
> implementation classes and have the generator inspect that folder at
> generation time. I.e., when generating a reference to
> org.example.foo.impl.BarImpl.java look to see if there is an
> org.example.foo.impl.BarImplCustom.java in that source folder and then
> use that instead of just BarImpl.
Simple indeed - this would only require two genmodel properties - the
hand-written code location & the extension suffix string.
> Of course the generated factory needs
> to refer to those custom impls as well, not just other derived
> implementation classes...
Unfortunately I don't see this solving my recurring need to override the
default generated factory, which is also named FooFactoryImplExt btw.
> The Xtext guys achieve their "generation cap"
> results effectively just by specializing the import manager using this
> approach...
>
> So feel free to open a bugzilla enhancement request.
Sure, will do.
|
|
|
| Re: [Xcore] multi-level class hierarchy extension [message #1094713 is a reply to message #1094496] |
Mon, 26 August 2013 05:04 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Amir,
Comments below.
On 25/08/2013 10:31 PM, Amir Sagie wrote:
> Thanks for the prompt feedback, comments below.
>
>> Yes, eventually I'll need to think about how to evolve Xcore so that one
>> could split from the same logical package across multiple resources.
> Why not build a xcore macro language? just kidding... ;]
The Xtext guys have something called active annotations for Xtend which
can be used to transform inferred models during the inference process.
That would be a cool thing, but wouldn't solve this type of problem...
> I'd be happy to
> use this to refactor type definitions out to a separate resource. A non
> circular include mechanism would work, and as a way to defer the decision
> which URL types would be supported (platform://, file:// namespace, etc)
> we could start by only supporting local root-model relative file
> references.
Perhaps just something as simple as logically merging multiple *.xcore
resources in the same folder and with the same nsURI into a single model
would do the trick.
>
> That being said I think this would have to depend on the xcore editor
> being able to present the fully expanded model, in the same way the ecore
> editor allows you to drill down any loaded resource.
Yes. Certainly Ecore itself supports cross resource containment for
EClassifiers, but Xtext doesn't support cross resource containment well
in general...
>
>>> I was wondering though what it would take to support wrapping around
>>> concrete EObject types, as attempted in the previous example:
>>>
>>> class B wraps main.AImplExt
>> That's already supported but doesn't mean what you intend. Ecore does
>> not model implementation classes directly, it models the API. What
>> you're asking for is a different code generation pattern.
> Well, this could be interpreted as sugar for 'extend all interfaces
> directly implemented by AImplExt', or perhaps a 'instance type name'
> annotation of some sort.
It's interpreted as, "don't generate an interface called B but rather
reuse the existing interface name wherever B would have been used."
>
>>> Is there any interest to support such a feature?
>> Yes, I would consider adding flexibility to the generator for the
>> "generation gap" pattern the Xtext folks are using. A relatively simple
>> approach is to define the source folder for your hand written
>> implementation classes and have the generator inspect that folder at
>> generation time. I.e., when generating a reference to
>> org.example.foo.impl.BarImpl.java look to see if there is an
>> org.example.foo.impl.BarImplCustom.java in that source folder and then
>> use that instead of just BarImpl.
> Simple indeed - this would only require two genmodel properties - the
> hand-written code location & the extension suffix string.
Yes.
>
>> Of course the generated factory needs
>> to refer to those custom impls as well, not just other derived
>> implementation classes...
> Unfortunately I don't see this solving my recurring need to override the
> default generated factory, which is also named FooFactoryImplExt btw.
It would work uniformly across all imported names... So the generated
FooFactoryImpl would see the extended class implementation names and use
them, and where the generated FooFactoryImpl itself is used (e.g., in
the package initialization code), it would notice there is a
FooFactoryImplExt class and use that...
>
>> The Xtext guys achieve their "generation cap"
>> results effectively just by specializing the import manager using this
>> approach...
>>
>> So feel free to open a bugzilla enhancement request.
> Sure, will do.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Apr 24 16:29:50 GMT 2024
Powered by FUDForum. Page generated in 0.03422 seconds |
] 
Search
Help
Register
Login
Home
