Home » Modeling » GMF (Graphical Modeling Framework) » does the notation model extend the ecore model?
| does the notation model extend the ecore model? [message #59711] |
Thu, 05 October 2006 14:27  |
Eclipse User |
|
|
|
Hi,
Why does the notation model contain elements that are subtypes of
elements in the ecore model, for example "View" is a subtype of
"EModelElement", "View" is declared in the notation package, while
"EModelElement" is coming from the ecore model.
In my understanding the ecore model is the model of all models, and
extending it is like merging two layers...?
I understand that it is perfectly legal to do this, but i thought one
better shouldnt touch the ecore model. This really confuses me.
Thanks for any comments,
Felix
|
|
|
| Re: does the notation model extend the ecore model? [message #59737 is a reply to message #59711] |
Thu, 05 October 2006 14:38  |
| Eclipse User |
|
|
|
Originally posted by: vcciubot.uwaterloo.ca
Take a look at:
http://dev.eclipse.org/viewcvs/indextools.cgi/*checkout*/org .eclipse.emf/doc/org.eclipse.emf.doc/references/overview/EMF .html
There's a lot of help provided on the emf newsgroup.
vlad
On Thu, 05 Oct 2006 20:27:38 +0200, Felix Dorner wrote:
> Hi,
>
> Why does the notation model contain elements that are subtypes of
> elements in the ecore model, for example "View" is a subtype of
> "EModelElement", "View" is declared in the notation package, while
> "EModelElement" is coming from the ecore model.
>
>
> In my understanding the ecore model is the model of all models, and
> extending it is like merging two layers...?
>
> I understand that it is perfectly legal to do this, but i thought one
> better shouldnt touch the ecore model. This really confuses me.
>
>
> Thanks for any comments,
>
> Felix
|
|
| |
| Re: does the notation model extend the ecore model? [message #60174 is a reply to message #60007] |
Fri, 06 October 2006 09:23 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Alex,
I always tell people, don't extend the Ecore model, but which I mean,
don't extend any EClass from EModelElement downward. It's not that this
is inherently evil, it's just that this introduces a dependency on
EModelElementImpl and we do not promise to keep binary compatibility for
our Impls (and in fact cannot due that adding features changes the
feature IDs for derived classes). Of course many people ignore this
advice, often because they made their decision before they were aware of
the advice. The usual reason given for ignoring the advice is that
EModelElement has those lovely EAnnotations that appear to be so highly
reusable. But they can be reused by defining a containment reference of
type EAnnotation on your own model's classes without extending
EModelElement and hence without introducing binary compatibilities
concerns, so it's not a very good reason for ignoring the advice. ;-)
Alex Shatalin wrote:
> Hello Vlad,
>
>> Take a look at:
>>
>> http://dev.eclipse.org/viewcvs/indextools.cgi/*checkout*/org .eclipse.e
>> mf/doc/org.eclipse.emf.doc/references/overview/EMF.html
>>
>> There's a lot of help provided on the emf newsgroup.
> Yes, but the question “why is it necessary to extend EModelElement
> by View?” is interesting for me as well. Are there any reasons to do
> it? (probably yes…) I suppose, somebody from the runtime team can
> comment it.
>
> -----------------
> Alex Shatalin
>
>
|
|
| |
| Re: does the notation model extend the ecore model? [message #60269 is a reply to message #60174] |
Fri, 06 October 2006 10:55 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
To play a little "devil's advocate": the problem with defining one's own
annotation feature is that EModelElement can be viewed as defining a common
"I am an annotatable element" type that can be understood by code that uses
Ecore reflection. Any code that wants to deal in a generic fashion with
annotations on annotatable elements would, otherwise, have to search for a
containment reference of type EAnnotation (probably preferring a reference
named 'eAnnotations', if there is one). It would be difficult to ensure
that the feature actually is intended for general-purpose annotations
(maybe a standard annotation on the annotation feature, itself, from the
ExtendedMetaData would help?).
Cheers,
Christian
Ed Merks wrote:
> Alex,
>
> I always tell people, don't extend the Ecore model, but which I mean,
> don't extend any EClass from EModelElement downward. It's not that this
> is inherently evil, it's just that this introduces a dependency on
> EModelElementImpl and we do not promise to keep binary compatibility for
> our Impls (and in fact cannot due that adding features changes the
> feature IDs for derived classes). Of course many people ignore this
> advice, often because they made their decision before they were aware of
> the advice. The usual reason given for ignoring the advice is that
> EModelElement has those lovely EAnnotations that appear to be so highly
> reusable. But they can be reused by defining a containment reference of
> type EAnnotation on your own model's classes without extending
> EModelElement and hence without introducing binary compatibilities
> concerns, so it's not a very good reason for ignoring the advice. ;-)
>
<snip>
|
|
| | |
| Re: does the notation model extend the ecore model? [message #60364 is a reply to message #60269] |
Fri, 06 October 2006 11:56 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------040906090605030605070303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
This is not particularly convincing. ;-) A few EcoreUtil methods would
be reusable, but that's about it. EModelElement was never intended as a
generic Annotatable API. It was intended to be the root object of Ecore
model's hierarchy. Also, generic code could act directly on the list
returned by getEAnntotation() or whatever the method is called in
another model. I could imagine defining an Annotatable API and mixing
that into ModelElement as a better approach. But this is all water
under the bridge and since there is a coordinated effort to release all
our plugins at once, the binary compatibility issues are of minimal concern.
Christian W. Damus wrote:
> Hi, Ed,
>
> To play a little "devil's advocate": the problem with defining one's own
> annotation feature is that EModelElement can be viewed as defining a common
> "I am an annotatable element" type that can be understood by code that uses
> Ecore reflection. Any code that wants to deal in a generic fashion with
> annotations on annotatable elements would, otherwise, have to search for a
> containment reference of type EAnnotation (probably preferring a reference
> named 'eAnnotations', if there is one). It would be difficult to ensure
> that the feature actually is intended for general-purpose annotations
> (maybe a standard annotation on the annotation feature, itself, from the
> ExtendedMetaData would help?).
>
> Cheers,
>
> Christian
>
>
> Ed Merks wrote:
>
>
>> Alex,
>>
>> I always tell people, don't extend the Ecore model, but which I mean,
>> don't extend any EClass from EModelElement downward. It's not that this
>> is inherently evil, it's just that this introduces a dependency on
>> EModelElementImpl and we do not promise to keep binary compatibility for
>> our Impls (and in fact cannot due that adding features changes the
>> feature IDs for derived classes). Of course many people ignore this
>> advice, often because they made their decision before they were aware of
>> the advice. The usual reason given for ignoring the advice is that
>> EModelElement has those lovely EAnnotations that appear to be so highly
>> reusable. But they can be reused by defining a containment reference of
>> type EAnnotation on your own model's classes without extending
>> EModelElement and hence without introducing binary compatibilities
>> concerns, so it's not a very good reason for ignoring the advice. ;-)
>>
>>
>
> <snip>
>
--------------040906090605030605070303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
This is not particularly convincing. ;-) A few EcoreUtil methods
would be reusable, but that's about it. EModelElement was never
intended as a generic Annotatable API. It was intended to be the root
object of Ecore model's hierarchy. Also, generic code could act
directly on the list returned by getEAnntotation() or whatever the
method is called in another model. I could imagine defining an
Annotatable API and mixing that into ModelElement as a better
approach. But this is all water under the bridge and since there is a
coordinated effort to release all our plugins at once, the binary
compatibility issues are of minimal concern.<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mideg5qoc$aqh$1@utils.eclipse.org" type="cite">
<pre wrap="">Hi, Ed,
To play a little "devil's advocate": the problem with defining one's own
annotation feature is that EModelElement can be viewed as defining a common
"I am an annotatable element" type that can be understood by code that uses
Ecore reflection. Any code that wants to deal in a generic fashion with
annotations on annotatable elements would, otherwise, have to search for a
containment reference of type EAnnotation (probably preferring a reference
named 'eAnnotations', if there is one). It would be difficult to ensure
that the feature actually is intended for general-purpose annotations
(maybe a standard annotation on the annotation feature, itself, from the
ExtendedMetaData would help?).
Cheers,
Christian
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Alex,
I always tell people, don't extend the Ecore model, but which I mean,
don't extend any EClass from EModelElement downward. It's not that this
is inherently evil, it's just that this introduces a dependency on
EModelElementImpl and we do not promise to keep binary compatibility for
our Impls (and in fact cannot due that adding features changes the
feature IDs for derived classes). Of course many people ignore this
advice, often because they made their decision before they were aware of
the advice. The usual reason given for ignoring the advice is that
EModelElement has those lovely EAnnotations that appear to be so highly
reusable. But they can be reused by defining a containment reference of
type EAnnotation on your own model's classes without extending
EModelElement and hence without introducing binary compatibilities
concerns, so it's not a very good reason for ignoring the advice. ;-)
</pre>
</blockquote>
<pre wrap=""><!---->
<snip>
</pre>
</blockquote>
<br>
</body>
</html>
--------------040906090605030605070303--
|
|
|
Goto Forum:
Current Time: Tue Jun 03 06:37:20 EDT 2025
Powered by FUDForum. Page generated in 0.04577 seconds |
Home