|
|
| Re: Generated interfaces [message #431134 is a reply to message #431133] |
Mon, 29 June 2009 23:27   |
 Jason Henriksen
Messages: 231
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Jason,
>
> Comments below.
>
> jason henriksen wrote:
>> Hi all,
>>
>> I came to a odd surprise today. I'm using EMF in an OSGI like
>> environment where the interfaces need to be in a separate class loader
>> from the implementations.
> That's your requirement?
>> I was very surprised to be reminded that the generated interface
>> contain a reference to the default implementations!
> XyzPackage.eINSTANCE you mean? It calls a static method that uses the
> registry would could in fact yield an override.
>> And it's not enough to just null out the interface variable, you
>> also have to change the constructor of the Impl not to reference the
>> variable in the interface.
> Which Impl?
>>
>> Has that been updated already?
> You could answer that yourself right? With the obvious answer being of
> course not, it's the way it's designed to work.
>> I'm still on EMF 2.4.2 so I know I'm quite a bit behind. But I
>> thought I'd ask since it seems like an odd choice. For now, I'm just
>> fixing my local JET templates.
> You've been pretty vague so far. Of course it's been this way always,
> so I'm not sure why you'd expect it to change...
>>
>> Thanks,
>>
>> Jason
Sorry, Ed. It's actually the .INSTANCE member that appears in the
FooPackage interface, not the .eINSTANCE that appears in the
FooPackageImpl. I think I got confused because it seems to be an
artifact of using the SDO generation style.
Anyways, sorry to be a bother. I was mostly just wondering why an
interface would ever want a member that refers to a specific impl class
and if there was some sage reason for it that I hadn't grasped yet.
Jason
|
|
|
| Re: Generated interfaces [message #431136 is a reply to message #431134] |
Tue, 30 June 2009 01:02 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Jason,
Given that nature of XyzPackage, i.e., the description of the model,
it's hard to imagine how there could be alternatives. XyzFactory is a
slightly different story, but consider the possibilities for how one
would get at the default instance. Is there anything other than a class
with a method that returns it? I.e., something just like the
XyzFactoryImpl's init method()? A call to a registry perhaps which
must return a generic result which is cast? Given it wasn't a design
point to specify a different factory nor to separate the bundles for the
interfaces and the implementations, we simply generated the simplest
thing...
jason henriksen wrote:
> Ed Merks wrote:
>> Jason,
>>
>> Comments below.
>>
>> jason henriksen wrote:
>>> Hi all,
>>>
>>> I came to a odd surprise today. I'm using EMF in an OSGI like
>>> environment where the interfaces need to be in a separate class
>>> loader from the implementations.
>> That's your requirement?
>>> I was very surprised to be reminded that the generated interface
>>> contain a reference to the default implementations!
>> XyzPackage.eINSTANCE you mean? It calls a static method that uses
>> the registry would could in fact yield an override.
>>> And it's not enough to just null out the interface variable, you
>>> also have to change the constructor of the Impl not to reference the
>>> variable in the interface.
>> Which Impl?
>>>
>>> Has that been updated already?
>> You could answer that yourself right? With the obvious answer being
>> of course not, it's the way it's designed to work.
>>> I'm still on EMF 2.4.2 so I know I'm quite a bit behind. But I
>>> thought I'd ask since it seems like an odd choice. For now, I'm
>>> just fixing my local JET templates.
>> You've been pretty vague so far. Of course it's been this way
>> always, so I'm not sure why you'd expect it to change...
>>>
>>> Thanks,
>>>
>>> Jason
>
> Sorry, Ed. It's actually the .INSTANCE member that appears in the
> FooPackage interface, not the .eINSTANCE that appears in the
> FooPackageImpl. I think I got confused because it seems to be an
> artifact of using the SDO generation style.
>
> Anyways, sorry to be a bother. I was mostly just wondering why an
> interface would ever want a member that refers to a specific impl
> class and if there was some sage reason for it that I hadn't grasped yet.
>
> Jason
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02040 seconds
] 
Search
Help
Register
Login
Home
