Eclipse Community Forums: EMF » Bidirectional navigation in model with inheritance

Help

Home

Home » Modeling » EMF » Bidirectional navigation in model with inheritance

Show: Today's Messages :: Show Polls :: Message Navigator

Bidirectional navigation in model with inheritance [message #703429]

Wed, 27 July 2011 15:04

Hernan Gonzalez

Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina

Senior Member

(Disclaimer: I'm a newbie at EMF) Say that, instead of the typical *Library-Books* bidirectional navigation sample case, I'd want to model something like this:

     interface AbstractLibrary {
        .....
    
     interface LibrarySimple extends AbstractLibrary {
         List<Book> getBooks();   // containment: true
    
     interface LibrarySpecial extends AbstractLibrary {
         List<Book> getBooksType1();  // containment: true
         List<Book> getBooksType2();  // containment: true

Because that I know that a Book must be have some AbstractLibrary as container, I want to have access to the parent:

      interface Book {
         AbstractLibrary getLibrary();

But, it seems, Eclipse-EMF does not allow me to declare those the references: for example, getBooksType1() only admits an opposite that returns a LibrarySpecial type (not the abstract supertype).

Which is the right way?

Report message to a moderator

Re: Bidirectional navigation in model with inheritance [message #703457 is a reply to message #703429]

Wed, 27 July 2011 15:34

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Hernan,

Comments below.

On 27/07/2011 8:04 AM, Hernan wrote:
> (Disclaimer: I'm a newbie at EMF) Say that, instead of the typical
> *Library-Books* bidirectional navigation sample case, I'd want to
> model something like this:
>
> interface AbstractLibrary {
> .....
> interface LibrarySimple extends AbstractLibrary {
> List<Book> getBooks(); // containment: true
> interface LibrarySpecial extends AbstractLibrary {
> List<Book> getBooksType1(); // containment: true
> List<Book> getBooksType2(); // containment: true
>
>
> Because that I know that a Book must be have some AbstractLibrary as
> container, I want to have access to the parent:
>
> interface Book {
> AbstractLibrary getLibrary();
>
> But, it seems, Eclipse-EMF does not allow me to declare those the
> references: for example, getBooksType1() only admits an opposite
> that returns a LibrarySpecial type (not the abstract supertype).
>
> Which is the right way?
A given Book instance, book, can be in at most one of the lists getBook,
getBooksType1(), or getBooksType2(). So while book.eContainer might
be some instance of AbstractLibrary or Library, library,
book.eContainmentFeature can be one of three different features. Any
given feature can have at most one opposite, and the opposite of the
opposite must be the feature itself...

I expect that the best approach in this case is to define an EOperation,
getLibrary, which checks that book.eContainmentReference is one of the
three possible features and cases EObject.eContainer() to
AbstractLibrary in that case; otherwise returns null.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Bidirectional navigation in model with inheritance [message #703495 is a reply to message #703457]

Wed, 27 July 2011 16:22

Hernan Gonzalez

Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina

Senior Member

Ed Merks wrote on Wed, 27 July 2011 11:34

I expect that the best approach in this case is to define an EOperation,
getLibrary, which checks that book.eContainmentReference is one of the
three possible features and cases EObject.eContainer() to
AbstractLibrary in that case; otherwise returns null.

I was plannig something similar: writing a method in BookImpl, say:

public AbstractLibrary getLibrary() {
  EObject container = book.eContainer();
  return container instanceof AbstractLibrary ? (AbstractLibrary)container : null;
}

I guess that to declare the method through a eOperation, as you suggest, would be more clean in that only then the Ecore model would "know" about it (right?) I'm not sure about the implicancies/advantages, but it sounds right.

What i'd like to understand is the difference between asking for the
book.eContainer class or, as you suggest, for the book.eContainmentReference. Is it equivalent?

Report message to a moderator

Re: Bidirectional navigation in model with inheritance [message #703528 is a reply to message #703495]

Wed, 27 July 2011 16:54

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Hernan,

Comments below.

On 27/07/2011 9:22 AM, Hernan wrote:
> Ed Merks wrote on Wed, 27 July 2011 11:34
>> I expect that the best approach in this case is to define an
>> EOperation, getLibrary, which checks that book.eContainmentReference
>> is one of the three possible features and cases EObject.eContainer()
>> to AbstractLibrary in that case; otherwise returns null.
>
>
> I was plannig something similar: writing a method in BookImpl, say:
>
> public AbstractLibrary getLibrary() {
> EObject container = book.eContainer();
> return container instanceof AbstractLibrary ?
> (AbstractLibrary)container : null;
> }
Yep, that works.
>
> I guess that to declare the method through a eOperation, as you
> suggest, would be more clean in that only then the Ecore model would
> "know" about it (right?)
Yes, and there's even support for eInvoke if you enable it. Not that
this buys you all much either...
> I'm not sure about the implicancies/advantages, but it sounds right.
Most likely it won't make a difference to you one way or the other...
> What i'd like to understand is the difference between asking for the
> book.eContainer class or, as you suggest, for the
> book.eContainmentReference. Is it equivalent?
Testing the the eContainmentFeature would be in place of doing an
instanceof test; it's potentially slightly better performing; how you
did it is perfectly fine though.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator