| Genmodel produces Object references rather than EObject - why? [message #505781] |
Mon, 04 January 2010 18:11  |
Eclipse User |
|
|
|
I'm using EMF 2.6M4 with Java compliance 6.0. I *was* using 2.5 and Java
compliance 5.0, but this behavior seems so strange I have to ask someone.
I have a method/operation defined in my ECore model as:
void pruneUnused(EObject scope),
i.e.
<eOperations name="pruneUnused">
<eParameters
name="scope"
eType="ecore:EClass http://www.eclipse.org/emf/2002/Ecore#//EObject"/>
</eOperations>
When I generate the Java code, it creates an interface method like this:
void pruneUnused(Object scope).
Note that it produces an *Object* parameter, rather than an *EObject*
parameter? Weird, huh?
Does anyone know why this is happening?
|
|
|
| Re: Genmodel produces Object references rather than EObject - why? [message #505782 is a reply to message #505781] |
Mon, 04 January 2010 18:18  |
| Eclipse User |
|
|
|
OK, Part of the way there.
It's because of the "Suppress EMF Types" flag in the genmodel options --
but this flag used to only be for collections, so that it would generate
List<?> rather than EList<?> for public methods, right?
Or is my recollection faulty and has this behavior always been there?
On 5/01/10 10:11 AM, Simon Pope wrote:
> I'm using EMF 2.6M4 with Java compliance 6.0. I *was* using 2.5 and Java
> compliance 5.0, but this behavior seems so strange I have to ask someone.
>
> I have a method/operation defined in my ECore model as:
>
> void pruneUnused(EObject scope),
>
> i.e.
>
> <eOperations name="pruneUnused">
> <eParameters
> name="scope"
> eType="ecore:EClass http://www.eclipse.org/emf/2002/Ecore#//EObject"/>
> </eOperations>
>
>
> When I generate the Java code, it creates an interface method like this:
>
> void pruneUnused(Object scope).
>
> Note that it produces an *Object* parameter, rather than an *EObject*
> parameter? Weird, huh?
>
> Does anyone know why this is happening?
|
|
|
|
| Re: Genmodel produces Object references rather than EObject - why? [message #505864 is a reply to message #505785] |
Tue, 05 January 2010 02:20 |
| Eclipse User |
|
|
|
Simon,
It's definitely working as intended. We generally expect that people
suppress EMF types when they want their APIs to be EMF free. So we'd
generally expect it to be used only when the generated interfaces also
don't extend EObject. Of course in that case, whenever an instance must
be passed an EObject-requiring method, casting will be required. We've
not change the behavior of the Suppress EMF Types flag in recent times...
Simon Pope wrote:
> OK, this just feels so wrong. Take a look at the code when EObject is
> replaced by Object as part of code generation:
>
> public void setKey(Object newKey) {
> Object oldKey = key;
> key = (EObject) newKey;
>
> if (eNotificationRequired())
> eNotify(new ENotificationImpl(this, Notification.SET,
> Package.CONTEXT__KEY, oldKey, key));
> }
>
> Spot the problem? Yep, its the cast of newKey to EObject. This is
> crazy and could lead to compiled code that will throw a
> ClassCastException if a non-EObject is passed as the key. I'm filing a
> bug over this one.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=298803
|
|
|
| Re: Genmodel produces Object references rather than EObject - why? [message #506066 is a reply to message #505864] |
Tue, 05 January 2010 19:03 |
| Eclipse User |
|
|
|
OK, well that makes sense.
On 5/01/10 10:50 PM, Ed Merks wrote:
> Simon,
>
> It's definitely working as intended. We generally expect that people
> suppress EMF types when they want their APIs to be EMF free. So we'd
> generally expect it to be used only when the generated interfaces also
> don't extend EObject. Of course in that case, whenever an instance must
> be passed an EObject-requiring method, casting will be required. We've
> not change the behavior of the Suppress EMF Types flag in recent times...
>
>
> Simon Pope wrote:
>> OK, this just feels so wrong. Take a look at the code when EObject is
>> replaced by Object as part of code generation:
>>
>> public void setKey(Object newKey) {
>> Object oldKey = key;
>> key = (EObject) newKey;
>>
>> if (eNotificationRequired())
>> eNotify(new ENotificationImpl(this, Notification.SET,
>> Package.CONTEXT__KEY, oldKey, key));
>> }
>>
>> Spot the problem? Yep, its the cast of newKey to EObject. This is
>> crazy and could lead to compiled code that will throw a
>> ClassCastException if a non-EObject is passed as the key. I'm filing a
>> bug over this one.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=298803
|
|
|
Powered by
FUDForum. Page generated in 0.03456 seconds
Home