|
| Re: Genmodel produces Object references rather than EObject - why? [message #505782 is a reply to message #505781] |
Mon, 04 January 2010 23:18   |
 Simon Pope
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
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 07:20 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Genmodel produces Object references rather than EObject - why? [message #506066 is a reply to message #505864] |
Wed, 06 January 2010 00:03 |
Simon Pope
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
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.02907 seconds
] 
Search
Help
Register
Login
Home
