Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Questions about EOperations
Questions about EOperations [message #631029] Tue, 05 October 2010 21:15 Go to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 301
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30553
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
>
Re: Questions about EOperations [message #631123 is a reply to message #631054] Wed, 06 October 2010 09:30 Go to previous message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 301
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
Previous Topic:save&load two packages in one file
Next Topic:Notation validation failing valid data
Goto Forum:
  


Current Time: Tue Oct 22 19:32:10 GMT 2019

Powered by FUDForum. Page generated in 0.01892 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top