Home » Modeling » EMF » Genmodel Operation Reflection Operation IDs
| Genmodel Operation Reflection Operation IDs [message #693720] |
Thu, 07 July 2011 04:48  |
 Michel Parisien
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hi,
I was reading the EMF book, and trying different options that can be specified in a genmodel file. I changed Operation Reflection to true, and generated the code, and looked at what happened.
Two things:
* First, eInvoke(int, EList) seems only accessible by the implementation, not the interface. Is this intentional? If the method is not exposed to the user, is it used by EObjectImpl or a supertype in some way?
* Second, I notice the generated index value for an eOperation I specified is 0. However, when I go to super.eInvoke(int, EList) (where super = EObjectImpl), it has EcorePackage.EOBJECT___ECLASS as value 0. Does that mean my operation arbitrarily overrides that operation, just because it happens to be the first one? I have a hard time not seeing this as a problem. I expected the index of the EOperation I specified to perhaps be EOBJECT_OPERATION_COUNT + 0. I'd like to know what, if anything, I am missing here.
Thank you.
|
|
|
| Re: Genmodel Operation Reflection Operation IDs [message #693724 is a reply to message #693720] |
Thu, 07 July 2011 05:19  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Michel,
Comments below.
On 06/07/2011 9:48 PM, Michel Parisien wrote:
> Hi,
>
> I was reading the EMF book, and trying different options that can be
> specified in a genmodel file. I changed Operation Reflection to true,
> and generated the code, and looked at what happened.
>
> Two things:
>
> * First, eInvoke(int, EList) seems only accessible by the
> implementation, not the interface. Is this intentional?
It's accessible via EObject just like eGet...
> If the method is not exposed to the user, is it used by EObjectImpl or
> a supertype in some way?
Nothing in the framework relies on it being there. It's available via
EObject for those who want to use it, but, because it's a new generated
capability, there's no guarantee that all models support it.
>
> * Second, I notice the generated index value for an eOperation I
> specified is 0. However, when I go to super.eInvoke(int, EList) (where
> super = EObjectImpl), it has EcorePackage.EOBJECT___ECLASS as value 0.
It depends on whether you explicitly (in the Ecore model) extend the
EClass for EObject...
> Does that mean my operation arbitrarily overrides that operation, just
> because it happens to be the first one?
No. It means you can't reflectively invoke EObject operations unless
you define yourself to be a subtype. Of course such reflective
invocation is basically pointless, given you can cast anything to
EObject and call the API directly.
> I have a hard time not seeing this as a problem.
It's not.
> I expected the index of the EOperation I specified to perhaps be
> EOBJECT_OPERATION_COUNT + 0. I'd like to know what, if anything, I am
> missing here.
No, we didn't want to pollute all APIs with EObject's operations,
especially given there's no little value in making them accessible in
that way...
>
> Thank you.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Genmodel Operation Reflection Operation IDs [message #693738 is a reply to message #693720] |
Thu, 07 July 2011 06:11 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Michael
Comments below
>
> I was reading the EMF book, and trying different options that can be
> specified in a genmodel file. I changed Operation Reflection to true,
> and generated the code, and looked at what happened.
>
> Two things:
>
> * First, eInvoke(int, EList) seems only accessible by the
> implementation, not the interface. Is this intentional? If the method
> is not exposed to the user, is it used by EObjectImpl or a supertype
> in some way?
This isn't a problem. eInvoke is one of the 'internal' mechanisms that
is available only after casting to exploit the InternalEObject interface.
>
> * Second, I notice the generated index value for an eOperation I
> specified is 0. However, when I go to super.eInvoke(int, EList) (where
> super = EObjectImpl), it has EcorePackage.EOBJECT___ECLASS as value 0.
> Does that mean my operation arbitrarily overrides that operation, just
> because it happens to be the first one? I have a hard time not seeing
> this as a problem. I expected the index of the EOperation I specified
> to perhaps be EOBJECT_OPERATION_COUNT + 0. I'd like to know what, if
> anything, I am missing here.
As of Helios M4, Ecore modeling semantics are closer to EMOF. EObject
methods are not overtly part of the EModelElement interface, therefore
they are not accessible by eInvoke() and so 'EOBJECT_OPERATION_COUNT' =
0. If you create a derived class you will find its features are as you
expect:
int MANAGER___HAS_NAME_AS_OPERATION = EMPLOYEE_OPERATION_COUNT + 1;
However I think that there may be an issue with overloading, fo which
I'll start a separate thread.
Regards
Ed Willink
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 03:38:00 GMT 2024
Powered by FUDForum. Page generated in 0.03598 seconds |
] 
Search
Help
Register
Login
Home
