Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Having a reference specify itself for the EOpposite
Having a reference specify itself for the EOpposite [message #1015089] Wed, 27 February 2013 12:12 Go to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 274
Registered: August 2009
Senior Member
Hello,

Suppose that I have a reference having the same EClass as source and destination (the EClass references itself). Why can't I specify this reference as an EOpposite as itself ?

There are cases where this might be useful. Suppose for instance that I have an EClass representing a gear wheel ("GearWheel") which contains a reference to itself (the reference specify the other GearWheel instance to which it is connected). In GearWheel1, if I specify that the connected gear wheel is GearWheel2, I would like that GearWheel2 reflects this as well, the same way an EOpposite reference works.

Is there a reason why something like that is not possible in EMF ? In the ecore editor (and also in the diagram editor), you can't select yourself (the reference) as EOpposite in this specific case.

BTW, this is a limitation of the EMF editor and the diagram editor, because it is perfectly possible to make such a model using the OCLinEcore editor: the generated ecore model is then featuring the EOpposite relation as expected. If I create a dynamic instance of such a model, the behavior is also reproduced (the GearWheel2 is updated when I selected it as a connected gear wheel).

Thanks,
Cédric
Re: Having a reference specify itself for the EOpposite [message #1015095 is a reply to message #1015089] Wed, 27 February 2013 12:57 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

You can. The most obvious example is Person.child and Person.parent.
These are same typed opposites. However Person.parent clearly cannot be
its own opposite.

Alternatively if you really have peers consider UML's Association and
Property. Association has two Property. An otherEnd helper disambiguates.

Regards

Ed Willink

On 27/02/2013 12:12, Cedric Moonen wrote:
> Hello,
>
> Suppose that I have a reference having the same EClass as source and
> destination (the EClass references itself). Why can't I specify this
> reference as an EOpposite as itself ?
>
> There are cases where this might be useful. Suppose for instance that
> I have an EClass representing a gear wheel ("GearWheel") which
> contains a reference to itself (the reference specify the other
> GearWheel instance to which it is connected). In GearWheel1, if I
> specify that the connected gear wheel is GearWheel2, I would like that
> GearWheel2 reflects this as well, the same way an EOpposite reference
> works.
>
> Is there a reason why something like that is not possible in EMF ? In
> the ecore editor (and also in the diagram editor), you can't select
> yourself (the reference) as EOpposite in this specific case.
>
> BTW, this is a limitation of the EMF editor and the diagram editor,
> because it is perfectly possible to make such a model using the
> OCLinEcore editor: the generated ecore model is then featuring the
> EOpposite relation as expected. If I create a dynamic instance of such
> a model, the behavior is also reproduced (the GearWheel2 is updated
> when I selected it as a connected gear wheel).
>
> Thanks,
> Cédric
Re: Having a reference specify itself for the EOpposite [message #1015098 is a reply to message #1015095] Wed, 27 February 2013 13:16 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 274
Registered: August 2009
Senior Member
Hi Ed,

Thanks for the reply.

You can. The most obvious example is Person.child and Person.parent. 
These are same typed opposites. However Person.parent clearly cannot be 
its own opposite.


This is not exactly the same thing: here we have two different references (and indeed, having parent as its own opposite doesn't make sense). However, suppose that we had another reference to person: "friends" (mutli-valued reference from Person to Person). In this case, you could make the reference its own opposite: if I add a friend called "Person1" to the friend list of "Person2", the list of friends of "Person1" should also contain "Person2" as a consequence. (This is a bit simplified since in practice, friendship is not always bilateral, but this is going outside the bounds of this discussion Razz ).

Alternatively if you really have peers consider UML's Association and 
Property. Association has two Property. An otherEnd helper disambiguates.


Yes this could be a solution but this makes the model navigation more complex, since I can't easily navigate from a gear wheel to its connected gear wheel.

Thanks,
Cédric
Re: Having a reference specify itself for the EOpposite [message #1015106 is a reply to message #1015098] Wed, 27 February 2013 13:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
Cedric,

It's just not supported. Oddities like "can I be my own friend" would
need special case handling that would make the general case less
efficient. Last time this issue came (and it has several times) I asked
Kenn Hussey about that and, if I recall correctly, even in CMOF the
properties on the ends of an association must be different properties.


On 27/02/2013 2:16 PM, Cedric Moonen wrote:
> Hi Ed,
>
> Thanks for the reply.
>
> You can. The most obvious example is Person.child and Person.parent.
> These are same typed opposites. However Person.parent clearly cannot
> be its own opposite.
>
> This is not exactly the same thing: here we have two different
> references (and indeed, having parent as its own opposite doesn't make
> sense). However, suppose that we had another reference to person:
> "friends" (mutli-valued reference from Person to Person). In this
> case, you could make the reference its own opposite: if I add a friend
> called "Person1" to the friend list of "Person2", the list of friends
> of "Person1" should also contain "Person2" as a consequence. (This is
> a bit simplified since in practice, friendship is not always
> bilateral, but this is going outside the bounds of this discussion :p ).
>
> Alternatively if you really have peers consider UML's Association and
> Property. Association has two Property. An otherEnd helper disambiguates.
>
> Yes this could be a solution but this makes the model navigation more
> complex, since I can't easily navigate from a gear wheel to its
> connected gear wheel.
>
> Thanks,
> Cédric
Re: Having a reference specify itself for the EOpposite [message #1015110 is a reply to message #1015106] Wed, 27 February 2013 13:49 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 274
Registered: August 2009
Senior Member
Hi Ed,

Thanks for the reply.

Quote:
It's just not supported.


It is not supported in the editor but there's no validation about this (since I was able to create an ecore model with another editor and I was able to generate the code).

Quote:
Oddities like "can I be my own friend" would
need special case handling that would make the general case less
efficient.


You have exactly the same problem with the parents and children relations: you can also perfectly add yourself as parent of yourself, which is as odd (or even more) as having yourself as a friend of your own.
So in both case you need some validation to reject invalid cases. So why is it allowed for a parent/child relation but not for a friend relation ?

Quote:
even in CMOF the properties on the ends of an association must be different properties.


I'm not sure I understood correctly but this would mean that a parent/children relation would be impossible, since for a parents reference, both ends are a Person. I guess I misunderstood what you meant here...

Thanks,
Cédric
Re: Having a reference specify itself for the EOpposite [message #1015121 is a reply to message #1015110] Wed, 27 February 2013 14:16 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 789
Registered: July 2009
Senior Member
Hi, Cedric,

In an association, the ends indicate "roles" that the associated
objects play. And these roles definitely indicate the relationship of
the object(s) at one end *to* the object(s) at the other end.

Even in the case of the friend association, there really are two roles:
"friend" and "friend of". A person that is its own friend is
permitted, but that just means that it plays both roles simultaneously.
A constraint may require that all friends also have their "friend of"s
as friends, but that's an additional constraint.

The remark about CMOF association ends needing to be different
properties simply means that an Association (which must have at least
two ends) cannot have repeated ends. Thus, a Friend association cannot
have the same Person::friend property as both ends. It must have,
e.g., Person::friend and Person::friendOf. Or, it can have
Person::friend and Friend::friendOf (an association-owned end, which
often means that the association is navigable only in one direction).
In Ecore this is just a reference without an opposite. Maybe that's
all that is actually needed in the friend case, after all? :-)

HTH,

Christian


On 2013-02-27 13:49:30 +0000, Cedric Moonen said:

> Hi Ed,
>
> Thanks for the reply.
>
> Quote:
>> It's just not supported.
>
>
> It is not supported in the editor but there's no validation about this
> (since I was able to create an ecore model with another editor and I
> was able to generate the code).
>
> Quote:
>> Oddities like "can I be my own friend" would need special case handling
>> that would make the general case less efficient.
>
>
> You have exactly the same problem with the parents and children
> relations: you can also perfectly add yourself as parent of yourself,
> which is as odd (or even more) as having yourself as a friend of your
> own.
> So in both case you need some validation to reject invalid cases. So
> why is it allowed for a parent/child relation but not for a friend
> relation ?
>
> Quote:
>> even in CMOF the properties on the ends of an association must be
>> different properties.
>
>
> I'm not sure I understood correctly but this would mean that a
> parent/children relation would be impossible, since for a parents
> reference, both ends are a Person. I guess I misunderstood what you
> meant here...
>
> Thanks,
> Cédric
Re: Having a reference specify itself for the EOpposite [message #1015131 is a reply to message #1015110] Wed, 27 February 2013 14:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
Cedric,

Comments below.


On 27/02/2013 2:49 PM, Cedric Moonen wrote:
> Hi Ed,
>
> Thanks for the reply.
>
> Quote:
>> It's just not supported.
>
>
> It is not supported in the editor but there's no validation about this
> (since I was able to create an ecore model with another editor and I
> was able to generate the code).
>
> Quote:
>> Oddities like "can I be my own friend" would need special case
>> handling that would make the general case less efficient.
>
>
> You have exactly the same problem with the parents and children
> relations: you can also perfectly add yourself as parent of yourself,
> which is as odd (or even more) as having yourself as a friend of your
> own.
It's not exactly the same problem because setting the parent involves
adding to the parent's child relation, and that's a different relation.
Adding adding x to be a friend of y would involve adding y to be a
friend of x, but they're different objects so also not a problem, but
the case of adding x as a friend of x you get into the odd case of
wanting to add x to the friends of x and then doing the inverse of also
wanting to add x to the friends of x, which is already in the process of
being done. You don't have have to take my word for the fact that
special handling is required, you can look at how this would behave in
the code yourself...
> So in both case you need some validation to reject invalid cases. So
> why is it allowed for a parent/child relation but not for a friend
> relation ?
>
> Quote:
>> even in CMOF the properties on the ends of an association must be
>> different properties.
>
>
> I'm not sure I understood correctly but this would mean that a
> parent/children relation would be impossible, since for a parents
> reference, both ends are a Person. I guess I misunderstood what you
> meant here...
Yes, parent and child themselves are two different features (properties
in UML terminology) so you can have an association for them. If I
recall correctly CMOF/UML allow n-ary associations but all the
properties must be different, so hence no binary association on the same
property...
>
> Thanks,
> Cédric
Re: Having a reference specify itself for the EOpposite [message #1015136 is a reply to message #1015131] Wed, 27 February 2013 14:48 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 274
Registered: August 2009
Senior Member
Quote:
Adding adding x to be a friend of y would involve adding y to be a
friend of x, but they're different objects so also not a problem, but
the case of adding x as a friend of x you get into the odd case of
wanting to add x to the friends of x and then doing the inverse of also
wanting to add x to the friends of x, which is already in the process of
being done.


Ah yes, this is indeed were things are different.

However, I tried on a dynamic instance of the domain model created via the OCLinEcore editor (so, the domain model containing a reference having itself as EOpposite) and everything works fine: if I try to add myself as for the reference, the property is set correctly and no exception is thrown. I end up with a consistent model (it might not be valid but that is the role of validation to reject such cases).
Maybe this case is too simple and in practice you can encounter situations where EMF would just throw an exception, I don't know...
Re: Having a reference specify itself for the EOpposite [message #1015190 is a reply to message #1015136] Wed, 27 February 2013 17:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
Cedric,

Is it multi-valued or single valued?

On 27/02/2013 3:48 PM, Cedric Moonen wrote:
> Quote:
>> Adding adding x to be a friend of y would involve adding y to be a
>> friend of x, but they're different objects so also not a problem, but
>> the case of adding x as a friend of x you get into the odd case of
>> wanting to add x to the friends of x and then doing the inverse of
>> also wanting to add x to the friends of x, which is already in the
>> process of being done.
>
>
> Ah yes, this is indeed were things are different.
>
> However, I tried on a dynamic instance of the domain model created via
> the OCLinEcore editor (so, the domain model containing a reference
> having itself as EOpposite) and everything works fine: if I try to add
> myself as for the reference, the property is set correctly and no
> exception is thrown. I end up with a consistent model (it might not be
> valid but that is the role of validation to reject such cases). Maybe
> this case is too simple and in practice you can encounter situations
> where EMF would just throw an exception, I don't know...
Re: Having a reference specify itself for the EOpposite [message #1015318 is a reply to message #1015190] Thu, 28 February 2013 08:31 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 274
Registered: August 2009
Senior Member
Single-valued.

Indeed, if I try on another example with a multi-valued reference, then it doesn't work properly anymore: trying to add a Person as a friend of itself ends up having the person twice in the list of friends...

I guess I'll have to look for a different way to express my domain-model.
Re: Having a reference specify itself for the EOpposite [message #1268984 is a reply to message #1015318] Tue, 11 March 2014 08:30 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 274
Registered: August 2009
Senior Member
Ed,

I'm bumping this since I updated to Luna and the EMF validation for EOpposite to self doesn't allow this case anymore (I was able to "cheat" by specifying that via the OCLinEcore editor).

My case: in my model, I have a GearWheel which specify to which other gear wheel it is connected to (via a reference called "connectedGearWheel" pointing to a GearWheel instance). Ideally, I would like to make this reference a EOpposite having itself as EOpposite, so that when I specify the connected gear wheel of one gear wheel, the reference in the other gear wheel is automatically updated.

Unfortunately, EMF doesn't support this scenario so I'm wondering how to make this work ? Should I adapt the generated code so that the setConnectedGearWheel method also calls the "setConnectedGearWheel" method of the other gear wheel (I should of course make sure to avoid infinite recursion) ?

What would be the best option to solve this problem ? Having two references with a different name is definitively not an option.

Thank you,
Cédric
Re: Having a reference specify itself for the EOpposite [message #1269066 is a reply to message #1268984] Tue, 11 March 2014 10:31 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
Cédric,

To keep things (the underlying frameworks) consistent I would still
suggest two separate features. You can suppress their visibility in the
API with annotations as created by
org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EStructuralFeature,
int, boolean). A third derived feature could be based on that pair,
i.e., the getter returning which ever feature is non-null, and the
setter setting whichever feature currently isn't null... The other
alternative is as you suggest, but it's likely to confuse things like a
copier; perhaps that won't hurt...


On 11/03/2014 9:30 AM, Cedric Moonen wrote:
> Ed,
>
> I'm bumping this since I updated to Luna and the EMF validation for
> EOpposite to self doesn't allow this case anymore (I was able to
> "cheat" by specifying that via the OCLinEcore editor).
>
> My case: in my model, I have a GearWheel which specify to which other
> gear wheel it is connected to (via a reference called
> "connectedGearWheel" pointing to a GearWheel instance). Ideally, I
> would like to make this reference a EOpposite having itself as
> EOpposite, so that when I specify the connected gear wheel of one gear
> wheel, the reference in the other gear wheel is automatically updated.
>
> Unfortunately, EMF doesn't support this scenario so I'm wondering how
> to make this work ? Should I adapt the generated code so that the
> setConnectedGearWheel method also calls the "setConnectedGearWheel"
> method of the other gear wheel (I should of course make sure to avoid
> infinite recursion) ?
>
> What would be the best option to solve this problem ? Having two
> references with a different name is definitively not an option.
>
> Thank you,
> Cédric
Re: Having a reference specify itself for the EOpposite [message #1269079 is a reply to message #1269066] Tue, 11 March 2014 10:58 Go to previous messageGo to next message
Cedric Moonen is currently offline Cedric Moonen
Messages: 274
Registered: August 2009
Senior Member
Actually, the ecore model is used to build a GMF editor. So, I am not sure how this will affect the generation of the GMF code...
Currently, I implemented it by adapting the setConnectedGearWheel and this seems to work fine. We won't need to copy the object, but I'm not sure if the GMF editor needs this or not...
Re: Having a reference specify itself for the EOpposite [message #1269083 is a reply to message #1269066] Tue, 11 March 2014 11:00 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

This does seem to be an unnecessary limitation.

Consider EMF's EReference.eOpposite:

The mutual opposite is not modeled in Ecore.ecore which allows
ill-formed models and requires a validateEReference_ConsistentOpposite
to enforce it.

Consider UML's Property.opposite

In UML, the modeling uses associations so is more obscure, but once
converted to UML.ecore it is also unmodeled but
PropertyImpl.setOpposite() enforces plausible association-mediated behavior.

So in the absence of EMF support, manual implementation of
GearWheeImpl.setConnectedGearWheel should do the job. You might prefer
to have a [0..1] multiplicity to accommodate the partially constructed
state.

Regards

Ed Willink

On 11/03/2014 10:31, Ed Merks wrote:
> Cédric,
>
> To keep things (the underlying frameworks) consistent I would still
> suggest two separate features. You can suppress their visibility in
> the API with annotations as created by
> org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EStructuralFeature,
> int, boolean). A third derived feature could be based on that pair,
> i.e., the getter returning which ever feature is non-null, and the
> setter setting whichever feature currently isn't null... The other
> alternative is as you suggest, but it's likely to confuse things like
> a copier; perhaps that won't hurt...
>
>
> On 11/03/2014 9:30 AM, Cedric Moonen wrote:
>> Ed,
>>
>> I'm bumping this since I updated to Luna and the EMF validation for
>> EOpposite to self doesn't allow this case anymore (I was able to
>> "cheat" by specifying that via the OCLinEcore editor).
>>
>> My case: in my model, I have a GearWheel which specify to which other
>> gear wheel it is connected to (via a reference called
>> "connectedGearWheel" pointing to a GearWheel instance). Ideally, I
>> would like to make this reference a EOpposite having itself as
>> EOpposite, so that when I specify the connected gear wheel of one
>> gear wheel, the reference in the other gear wheel is automatically
>> updated.
>>
>> Unfortunately, EMF doesn't support this scenario so I'm wondering how
>> to make this work ? Should I adapt the generated code so that the
>> setConnectedGearWheel method also calls the "setConnectedGearWheel"
>> method of the other gear wheel (I should of course make sure to avoid
>> infinite recursion) ?
>>
>> What would be the best option to solve this problem ? Having two
>> references with a different name is definitively not an option.
>>
>> Thank you,
>> Cédric
>
Previous Topic:XMLResource Save Problem
Next Topic:Create empty XML from XSD generated Epackage
Goto Forum:
  


Current Time: Sat Sep 20 10:00:56 GMT 2014

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

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