|
|
| registration of behavorial extensions and operation behavior annotations. [message #415739 is a reply to message #415696] |
Fri, 04 January 2008 16:24   |
 Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi, Ed.
Is there a feature request for this, for which we can vote, or shall I
open one?
Regards, Philipp
Ed Merks wrote:
> Eric,
>
> Enums in the metamodels existed long before they did in Java. It's
> certainly possible to consider adding them to EEnum but next we'd get
> into issues of EEnums could implement interfaces and hence are sort of
> more like EClasses (but of course enums can't extend classes or other
> enums); the complexity would quickly grow to accommodate all that. If
> we had better support for specifying the behavior of EOperations, it
> would become more interesting. On that front, I've really wanted to be
> able to come up with some type of mechanism whereby behavioral
> extensions could register themselves and operation behaviors could be
> specified via annotations on the operation (sort of like the body
> annotation allows a snip of Java code to be specified, but more dynamic
> so it would actually work for dynamic models rather than only for
> generated models).
>
>
> Eric Rizzo wrote:
>> I've been wondering why the .ecore editor does not allow to add an
>> operation to an EEnum. I would guess that the meta-model does not
>> provide for it, but I don't understand why; after all, Java enums can
>> have methods...
>>
>> Eric
|
|
|
|
|
| Re: Why no Operations on EEnums? [message #415802 is a reply to message #415745] |
Mon, 07 January 2008 16:01 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Guys,
>
> This just doesn't strike me as one of life's big priorities. Next
> you'll want a different implementation of the operation for each
> literal! Worms get out through very small holes after all! :-P
One could argue that you needn't be concerned with what "we" will want
next, just with what "we" ask for now. ;-)
I guess I can't argue with your choice of priorities. I just see this as
a pretty obvious gap in the ECore meta-model that I think would be easy
to fill.
On a general note, if we want MDD using EMF to be increasingly adopted I
would think we'd want to minimize the places where one has to drop to
injected hand-written code in order to model a system. This represents
one of those situations, where the ECore model does not support a common
construct.
I'll probably enter an enhancement request for posterity; if I had time
I'd familiarize myself with ECore and EMF internals and try to provide a
patch, but unfortunately I'm buried for the next few months. :-(
Eric
> Eric Rizzo wrote:
>> Ed Merks wrote:
>>> Eric,
>>>
>>> Enums in the metamodels existed long before they did in Java. It's
>>> certainly possible to consider adding them to EEnum but next we'd get
>>> into issues of EEnums could implement interfaces and hence are sort
>>> of more like EClasses (but of course enums can't extend classes or
>>> other enums); the complexity would quickly grow to accommodate all that.
>>
>> I don't see why you would necessarily have to open the "EENums
>> implemeting interfaces" can of worms. As I see it, allowing
>> EOperations on EEnums would be a lot simpler both conceptually and
>> from an implementation standpoint, but adding that capability does not
>> *necessarily* lead to having to support interfaces. Interfaces would
>> be a logical next step, but not required just to allow EOperations.
>>
>> Eric
>>
>>
>>>
>>> Eric Rizzo wrote:
>>>> I've been wondering why the .ecore editor does not allow to add an
>>>> operation to an EEnum. I would guess that the meta-model does not
>>>> provide for it, but I don't understand why; after all, Java enums
>>>> can have methods...
>>>>
>>>> Eric
|
|
|
Powered by
FUDForum. Page generated in 0.92167 seconds
] 
Search
Help
Register
Login
Home
