Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Overriding Feature lowerBound
Overriding Feature lowerBound [message #1814904] Sun, 22 September 2019 11:23 Go to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
Looking for a solution to a problem where I have an abstract class/interface defined in my Ecore and that is used in many places. This represents a pair of attributes (start and end date). At the moment the cardinality is set to 0-1. But in specific classes one or both of those values are required.

So how can I override the ETypedElement#getLowerBound selectively? or is there a way to initialize those differently from the package loading ?

Thanks
Alain
Re: Overriding Feature lowerBound [message #1814913 is a reply to message #1814904] Sun, 22 September 2019 16:01 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 30684
Registered: July 2009
Senior Member
You cannot override such a thing in the model. But in a specific subclass you can declare and implement a constraint that enforces whatever rule you might desire specifically for that class' of instances. A similar example is ETypedElement.eType, which has lowerBound=0, but only an EOperation can have an eType that isn't set; it's enforced by org.eclipse.emf.ecore.util.EcoreValidator.validateETypedElement_ValidType(ETypedElement, DiagnosticChain, Map<Object, Object>); because the model is "closed", i.e., all subclasses are known, we can implement the constraint on the base class itself.
Re: Overriding Feature lowerBound [message #1814914 is a reply to message #1814913] Sun, 22 September 2019 17:01 Go to previous messageGo to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
Thanks Ed, that's what I feared.

As you stated validations can be implemented, but the standard UI mechanism to determine if a feature is required and show the input control differently rely on cardinality and so does the validation at the same time. Here it means providing a customized validation and a customized control variant.

Alain
Re: Overriding Feature lowerBound [message #1814915 is a reply to message #1814914] Sun, 22 September 2019 18:18 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 30684
Registered: July 2009
Senior Member
I'm not sure to which controls you refer; certainly the properties view doesn't show different controls for optional versus required things. Which control and how is it different?

Note too, for example, that the Ecore Editor shows you an error in the properties view and in the tree view itself if you enable Live Validation in the menu; and this support for live validation can be generated for any model (Editor -> Decoration in the *.genmode's properties view).
Re: Overriding Feature lowerBound [message #1814916 is a reply to message #1814915] Sun, 22 September 2019 18:57 Go to previous messageGo to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
I'm referring to ECP (or what we now use that is derived from it)

See image with red star, indicating a required field and the red border here with the exclamation point and message below coming from the validator.
Re: Overriding Feature lowerBound [message #1814931 is a reply to message #1814916] Mon, 23 September 2019 07:04 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6534
Registered: July 2009
Senior Member
Hi

In an ideal world, all derived classes would always satisfy the is-a relationship wrt their base classes.

In a practical world, this is sometimes awkward as you have found with the lowerbound stylized constraint.

Without abandoning OO principles, the solution is to make your required behavioral variation a permitted variation using the only tool available - operation overloading.

Thus in UML, the NamedElement::isDistinguishableFrom() predicate makes the uniqueness/distinguishability of names a behavior that derived classes can configure and allows Namespace operations such as excludeCollisions to operate even though simple is-a is broken.

Regards

Ed Willink
Re: Overriding Feature lowerBound [message #1814949 is a reply to message #1814931] Mon, 23 September 2019 11:09 Go to previous message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
Thanks for the tip Ed.
Previous Topic:Is it possible to change the return type of EObjectContainmentEList?
Next Topic:Genmodel warnings with 2019-06
Goto Forum:
  


Current Time: Fri Dec 06 11:33:52 GMT 2019

Powered by FUDForum. Page generated in 0.01563 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top