| Questions about EOperations [message #631029] |
Tue, 05 October 2010 21:15  |
 Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Hi all,
I am currently working with some more advanced EOperation stuff and I
have come across some oddities:
1. An EClass can be defined abstract, but there is no way to mark an
EOperation as abstract (or final, e.g.). Why is that? Is there a reason
that there are no abstract or final properties for an EOperation?
2. The generated EPackage code contains IDs and Literals for EClasses
and EStructuralFeatures, but not for EOperations. Has this been
forgotten? In fact, I don't see a way symbolically reference an
EOperation in, e.g., a call to eClass.getEOperation(int id). And, as a
side note, even the generated code for invocation delegates hard-codes
the numerical ID into this call instead of referring to a package
constant. This appears a bit suboptimal in m eyes.
Are those Bugs? Unimplemented Enhancements? Or even features, which I
haven't understood so far?
Thanks for any enlightenment!
Cheers
Stefan
|
|
|
| Re: Questions about EOperations [message #631054 is a reply to message #631029] |
Tue, 05 October 2010 23:45  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Stefan,
Comments below.
Stefan Winkler wrote:
> Hi all,
>
> I am currently working with some more advanced EOperation stuff and I
> have come across some oddities:
>
> 1. An EClass can be defined abstract, but there is no way to mark an
> EOperation as abstract (or final, e.g.). Why is that? Is there a reason
> that there are no abstract or final properties for an EOperation?
>
Because neither of these apply in interfaces and that's primarily what
models are being used to describe...
> 2. The generated EPackage code contains IDs and Literals for EClasses
> and EStructuralFeatures, but not for EOperations.
You can to enable that. Did you do that? Operation Reflection set to
true...
> Has this been
> forgotten?
Until support for eInvoke was added, it wasn't needed for anything.
> In fact, I don't see a way symbolically reference an
> EOperation in, e.g., a call to eClass.getEOperation(int id). And, as a
> side note, even the generated code for invocation delegates hard-codes
> the numerical ID into this call instead of referring to a package
> constant. This appears a bit suboptimal in m eyes.
>
You mean in package initialization?
> Are those Bugs? Unimplemented Enhancements? Or even features, which I
> haven't understood so far?
>
> Thanks for any enlightenment!
>
> Cheers
> Stefan
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Questions about EOperations [message #631123 is a reply to message #631054] |
Wed, 06 October 2010 09:30 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Hi Ed,
comments below.
On 06.10.2010 01:45, Ed Merks wrote:
> Stefan,
>
> Comments below.
>
> Stefan Winkler wrote:
>> Hi all,
>>
>> I am currently working with some more advanced EOperation stuff and I
>> have come across some oddities:
>>
>> 1. An EClass can be defined abstract, but there is no way to mark an
>> EOperation as abstract (or final, e.g.). Why is that? Is there a reason
>> that there are no abstract or final properties for an EOperation?
> Because neither of these apply in interfaces and that's primarily what
> models are being used to describe...
I see. But on the other hand, these properties would be handy for code
generation. (Naturally, you can always add the modifiers and a
"@generated NOT" tag manually ...)
But anyway, I see a use case for that: one could design extensible
models (frameworks) with these properties...
>> 2. The generated EPackage code contains IDs and Literals for EClasses
>> and EStructuralFeatures, but not for EOperations.
> You can to enable that. Did you do that? Operation Reflection set to
> true...
Doh, I looked for such an option yesterday but missed it. Thanks for
pointing this out.
>> Has this been
>> forgotten?
> Until support for eInvoke was added, it wasn't needed for anything.
>> In fact, I don't see a way symbolically reference an
>> EOperation in, e.g., a call to eClass.getEOperation(int id). And, as a
>> side note, even the generated code for invocation delegates hard-codes
>> the numerical ID into this call instead of referring to a package
>> constant. This appears a bit suboptimal in m eyes.
> You mean in package initialization?
In the cached invocation delegate field in the class implementation
itself. But if I set the reflection option, then the symbolic name is
used here as well.
As always: thanks for your quick response!
Cheers,
Stefan
|
|
|
Powered by
FUDForum. Page generated in 0.03556 seconds
] 
Search
Help
Register
Login
Home
