|
|
| Re: Xcore - single container, multiple opposite [message #1008344 is a reply to message #1008179] |
Tue, 12 February 2013 05:29  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 11/02/2013 10:45 AM, David Michonneau wrote:
> Hi,
>
> I'm trying to implement a model similar to this:
>
> package test
> class Car {
> contains Tire leftTire contains Tire rightTire }
>
> class Tire {
> container Car car // not allowed by Xcore editor
> }
You must specify exactly one containment reference as the opposite.
>
> Unfortunately, it is not possible because container requires an
> opposite. I found the only way to make it work is as follows:
>
> class Car {
> contains Tire leftTire opposite carForLeftTire contains Tire
> rightTire opposite carForRightTire
> }
>
> class Tire {
> container Car carForLeftTire opposite leftTire
> container Car carForRightTire opposite rightTire
> }
>
> However in this case, this just makes the generated code not really
> convenient to use to find the car of a given tire. I found I could do
> an operation like:
>
> class Tire {
> op Car getCar() {
> return this.eContainer() as Car
> }
>
> but shouldn't the generation supports this use case?
You'd have to be more careful (an instanceof check) because the
container could be something else as well.
> Why is the container keyword constrained to specify an opposite?
It's this way in Ecore as well. A reference is a container reference by
virtue of being the opposite of a containment reference; it's not a bit
you can set independently.
Note that in your second approach, it's less convenient to get the car,
but more importantly the tire.setCarForLeftTire and
tire.setCarForRightTire do the right thing (adds it to the proper
containment reference of the car), whereas tire.setCar can't possibly do
the right thing.
>
> Thanks,
>
> David
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03586 seconds
] 
Search
Help
Register
Login
Home
