Eclipse Community Forums: EMF » [Xcore] Reference properties are always unique in Ecore derived from Xcore

Help

Home

Home » Modeling » EMF » [Xcore] Reference properties are always unique in Ecore derived from Xcore

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

[Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1787650]

Wed, 30 May 2018 12:50

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

Hi

Here is a simple Xcore model:

package test

class ClassA {
    contains ClassB children
}

class ClassB { }

I open this model with "Reflective Xcore Model Editor" and I see 3 packages: XPackage, GenModelPackage, EPackage.

The children property is non-unique in XPackage as expected (see left part of attached picture). But this property is unique in the derived EPackage (see right part of attached picture). Why it's marked as unique?

Attachment: xcore-unique.png
(Size: 33.65KB, Downloaded 81 times)

Report message to a moderator

Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1787803 is a reply to message #1787650]

Wed, 30 May 2018 14:10

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

All EReferences are treated as unique. That's certainly necessary for containment and bidirectional references, though not strictly necessary for one-way cross references: https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325

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

Report message to a moderator

Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789873 is a reply to message #1787803]

Thu, 31 May 2018 08:25

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

The problem is that an Xcore model and an derived Ecore model are inconsistent. I have an Xtend-based code generator. When I generate code for an XPackage everithing works as expected. But when I execute a similar codegenerator for EPackage contained in the same resource (and derived from the XPackage) all references becomes unique. I think references must be unique or non unique in both XPackage and EPackage.

Oh, I've found a workaround: https://bugs.eclipse.org/bugs/show_bug.cgi?id=467855
@Ecore(^unique="false")

But if I can mark a reference as non-unique using the annotation, why it can't be marked automatically?..

Report message to a moderator

Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789879 is a reply to message #1789873]

Thu, 31 May 2018 10:15

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

The Xcore model is not intended to be something from which you directly generate code. The GenModel in combination with the Ecore model is intended for that purpose. The Xcore model's only intended purpose is to represent the syntax from which to derive a GenModel and an Ecore model. Given that EMF's generator doesn't support generating non-unique references nor is this supported for dynamic EMF models, it's kind of irrelevant at which value this attribute has.

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

Report message to a moderator

Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789883 is a reply to message #1789879]

Thu, 31 May 2018 10:52

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

I agree, code generation from an Xcore model was really painful. EMF's generator doesn't support non-unique references, but I write my own generator. And I guess there could exists a number of alternative code generators, which use Ecore models as an input.

Report message to a moderator

Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789888 is a reply to message #1789883]

Thu, 31 May 2018 11:32

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

In any non-trivial model there will almost inevitably be some redundant state such as whether a [1..1] multiplicity element is ordered and/or unique. UML and Ecore are identical with respect to this redundancy although different with respect to the corresponding defaults.

Arguably it would change the surprise into a bug if EMF imposed a fixed value on the redundant state, either silently, or through validation warnings. But the consequent non-equality of functionally identical models is unfortunate.

For my testing purposes, I have taken to introducing a pre-normalization that folds all redundant state to deterministic values before comparing models for equality.

(The accidental ordering of non-ordered collections is another irrelevance that normalization can eliminate.)

Regards

Ed Willink

Report message to a moderator

Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789942 is a reply to message #1789888]

Fri, 01 June 2018 06:20

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

Oh, I've got it.

@Ecore(^unique="false") works only for single-valued references. For multi-valued reference one will get the following error: "A containment or bidirectional reference must be unique if its upper bound is different from 1"

Xcore models aren't equivalent to Ecore models! Ecore models doesn't support non-unique multi-valued references. But Xcore models support them:

package test

class ClassA {
    contains ClassB[] nonUniqueChildren
    contains unique ClassB[] uniqueChildren
}

class ClassB { }

What is a purpose of 'unique' keyword in Xcore? Should it be used only for multi-valued attributes (and not for references)? Or it can be used for multi-valued references as well? And Ecore must also support them?

Prohibition of non-unique multi-valued references complicates a little bit usage of Ecore as a modeling language for custom code generators... I think Ecore should be a more generic modeling language and it shouldn't be so highly coupled with EMF code generator.

Report message to a moderator

Re: [Xcore] Reference properties are always unique in Ecore derived from Xcore [message #1789947 is a reply to message #1789942]

Fri, 01 June 2018 06:57

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

I prefer not to go in circles on this subject. I've already pointed you at https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325 which hightlights the fact that in no case is a non-unique EReference supported, i.e., not in the generator, not at runtime (even for dynamic models), and not in any of the downstream frameworks which assume uniqueness. Have you looked at this?

So at this point, the value of the unique feature on an EReference is actually kind of pointless, and as you note, the unique keyword on an XReference is also pointless. It's only really meaningfully implemented and supported for EAttributes and even there it's pointless unless the upper bound is > 1.

Ecore is intended to support its own runtime and the generator is designed to support this runtime as well. If you want to use Ecore for some other purpose (that doesn't use the EMF runtime) you can of course add your own arbitrary annotations (XAnnotations that map to EAnnotations) to capture any additional/different information you need/want in order to generate something unrelated to EMF/Ecore. Best you not expect Ecore to change at this point in its long life to conform to some other ideal that you might imagine...

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

Report message to a moderator

Previous Topic:	MDA
Next Topic:	[XCore] .xcore header comments parsing problem

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 20:58:21 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter