Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Xcore - single container, multiple opposite
Xcore - single container, multiple opposite [message #1008179] Mon, 11 February 2013 04:45 Go to next message
David Michonneau is currently offline David Michonneau
Messages: 85
Registered: July 2009
Member
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 #1008280 is a reply to message #1008179] Mon, 11 February 2013 07:50 Go to previous messageGo to next message
Roland Tepp is currently offline Roland Tepp
Messages: 36
Registered: July 2009
Member
Can't you solve this with feature maps?

11.02.2013 11:45, David Michonneau kirjutas:
> 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 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 25952
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
>
Previous Topic:[EMF] Loading XML file with no namespace information
Next Topic:Nested Properties in EMF
Goto Forum:
  


Current Time: Sat Aug 02 04:39:01 EDT 2014

Powered by FUDForum. Page generated in 0.02433 seconds