[news.eclipse.tools.emf] Re: uml2.ecore mistake

[Cyril Faucher <cfaucher@xxxxxxxx>]

Ed,

I think there is a redundancy, I mean:

The context:
EClass Element
Element.owner as type Element (derived)
Element.ownedElement as type Element (derived)
Element.owner and Element.ownedElement are opposite

If I want to get the value of Element.owner then I am using the 
implementation of the dedicated getter. The same thing for 
Element.ownedElement.
Now, if I have a setter on Element.owner, I am using the implementation 
of the dedicated setter. This setter could not impact the value of 
Element.owner then Element.ownedElement (opposite) will be not updated.

Finally, in my opinion and in this specific case, the opposite is there 
just there for a semantic sugar, but ignored in the rest.

Cyril.

Ed Merks a écrit :
> Cyril,
>
> It sounds okay to me, especially if they are derived from references 
> that are similarly paired as opposites.  Why do you think it doesn't 
> make sense?
>
>
> Cyril Faucher wrote:
> > Hi,
> >
> > I have a question about the metamodel of uml2: uml2.ecore.
> > The EClass "Element" has 2 EReferences "owner" and "ownedElement".
> > These 2 EReferences are derived.
> > My problem is: why they are opposite, I guess that comes from the 
> > translation of an UML Association in Ecore.
> >
> > For me, I think that does not make sense in Ecore to have 2 derived 
> > EReferences and opposite.
> >
> > Best regards,
> > Cyril.