Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Are null-able Enums still supported?
Are null-able Enums still supported? [message #805602] Fri, 24 February 2012 00:00 Go to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 51
Registered: August 2009
Member
Use of "wrapper" data types for EEnum (using org.eclipse.emf.common.util.Enumerator) for null-ability is a common pattern in Ecore, and used to be supported well in MDT/OCL. Is it still intended to be supported in the new implementation and editors?

Currently (tried both SR1 and M5) wrapping e.g. the RoyalAndLoyal's Gender enum into GenderObject (attached) causes the CompleteOCL editor to flag the relevant constraint

inv invariant_Customer7 :
	(self.gender = Gender::male) implies self.title = 'Mr.'

with an error
Unresolved operation '=' for 'RoyalAndLoyal.ecore::RandL::GenderObject' and 'RoyalAndLoyal.ecore::RandL::Gender'


Also Xtext OCL console in SR1 does not let one evaluate Customer.gender:

Evaluating:
self.gender
Results:
Evaluation failure
Failed to evaluate RoyalAndLoyal.ecore::RandL::Customer.gender


Xtext OCL in M5 evaluates (correctly for my test case) to
Evaluating:
self.gender
Results:
RoyalAndLoyal.ecore::RandL::Gender::male


Old OCL console evaluates and compares fine:

Evaluating:
self.gender = Gender::male
Results:
true
Re: Are null-able Enums still supported? [message #805941 is a reply to message #805602] Fri, 24 February 2012 10:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4154
Registered: July 2009
Senior Member
Hi

The intended semantics is that an Enumeration (or Boolean, or Integer or
String ...) is both nullable and not nullable, determined by its
cardinality.

i.e
nullableEnum : MyEnum[?]
nonnullableEnum : MyEnum[1]

both may exhibit invalid, null or literals as their values, but a null
value is only well-formed for nullableEnum.

(This is not yet part of the OCL specification; it just arose as the
obviously correct semantics after discussion of alternatives.)

Introducing a MyEnumObject in the style of EBooleanObject might work if
both have the same instanceClassName, but I have some FIXMEs to localize
the normalisation of declaration and implementation types becuase I keep
finding places where it's not performed.

I recall fixing an embarrassing bug on enumeration literals, but I can't
see it the N&N. I suspect it went in to M3.

Regards

Ed Willink


On 24/02/2012 00:00, Alex Mising name wrote:
> Use of "wrapper" data types for EEnum (using org.eclipse.emf.common.util.Enumerator) for null-ability is a common pattern in Ecore, and used to be supported well in MDT/OCL. Is it still intended to be supported in the new implementation and editors?
>
> Currently (tried both SR1 and M5) wrapping e.g. the RoyalAndLoyal's Gender enum into GenderObject (attached) causes the CompleteOCL editor to flag the relevant constraint
>
> inv invariant_Customer7 :
> (self.gender = Gender::male) implies self.title = 'Mr.'
>
> with an error Unresolved operation '=' for 'RoyalAndLoyal.ecore::RandL::GenderObject' and 'RoyalAndLoyal.ecore::RandL::Gender'
>
> Also Xtext OCL console in SR1 does not let one evaluate Customer.gender:
>
> Evaluating:
> self.gender
> Results:
> Evaluation failure
> Failed to evaluate RoyalAndLoyal.ecore::RandL::Customer.gender
>
> Xtext OCL in M5 evaluates (correctly for my test case) to
> Evaluating:
> self.gender
> Results:
> RoyalAndLoyal.ecore::RandL::Gender::male
>
> Old OCL console evaluates and compares fine:
>
> Evaluating:
> self.gender = Gender::male
> Results:
> true
Re: Are null-able Enums still supported? [message #806213 is a reply to message #805941] Fri, 24 February 2012 17:57 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 51
Registered: August 2009
Member
Thanks, good to hear it is being addressed at the OCL specification level.

From the point of view of "wrapped" enumeration pattern in Ecore, there seem to be two pieces to this. One is being able to instantiate this pattern in model definition parts of OCL, e.g. in OCLinEcore - and I think your answer is related to this.

The second is being able to evaluate OCL expressions using Ecore models [possibly already] exhibiting this pattern. My question was about the latter, since it worked (and works) fine with "mature" OCL, but does not seem to work in the new one - or maybe it is just the new editors?

The pattern itself is probably not uncommon in Ecore. EMF book describes it the context of mapping XSD nillalble elements to Ecore (9.2.2, 9.5.4), so it is most likely to surface in XSD-derived models, but there are other uses as well ...

Just for reference, here is what OCLinEcore looks like for when Gender enum in RoyalAndLoyal is wrapped into GenederObject:

datatype GenderObject : 'org.eclipse.emf.common.util.Enumerator' { serializable }
{
	annotation _'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'
	(
		'name' = 'Gender:Object',
		'baseType' = 'Gender'
	);
}

[Updated on: Fri, 24 February 2012 17:57]

Report message to a moderator

Re: Are null-able Enums still supported? [message #806250 is a reply to message #806213] Fri, 24 February 2012 18:42 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4154
Registered: July 2009
Senior Member
Hi

Thanks for bringing this idiom to my attention.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=372531 raised.

Regards

Ed Willink

On 24/02/2012 17:57, Alex Mising name wrote:
> datatype GenderObject : 'org.eclipse.emf.common.util.Enumerator' {
> serializable }
> {
> annotation _'http:///org/eclipse/emf/ecore/util/ExtendedMetaData'
> (
> 'name' = 'Gender:Object',
> 'baseType' = 'Gender'
> );
> }
Previous Topic:[Announce] Eclipse OCL 3.1.2 and OCL 3.1.2a (Indigo SR2) is now available
Next Topic:CompleteOCL errors against UML model.
Goto Forum:
  


Current Time: Wed Nov 26 22:00:29 GMT 2014

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

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