| Xcore - single container, multiple opposite [message #1008179] |
Mon, 11 February 2013 04:45  |
Eclipse User |
|
|
|
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
}
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? Why is the container keyword constrained to specify an opposite?
Thanks,
David
|
|
|
|
| Re: Xcore - single container, multiple opposite [message #1008344 is a reply to message #1008179] |
Tue, 12 February 2013 00:29  |
| Eclipse User |
|
|
|
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
>
|
|
|
Powered by
FUDForum. Page generated in 0.04314 seconds
Home