Eclipse Community Forums: OCL » Are null-able Enums still supported?

Help

Home

Home » Modeling » OCL » Are null-able Enums still supported?

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

Are null-able Enums still supported? [message #805602]

Fri, 24 February 2012 00:00

Alex Mising name

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

Attachment: RoyalAndLoyal.ecore
(Size: 29.27KB, Downloaded 342 times)
Attachment: Customer.xmi
(Size: 0.41KB, Downloaded 288 times)

Report message to a moderator

Re: Are null-able Enums still supported? [message #805941 is a reply to message #805602]

Fri, 24 February 2012 10:18

Ed Willink

Messages: 7655
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

Report message to a moderator

Re: Are null-able Enums still supported? [message #806213 is a reply to message #805941]

Fri, 24 February 2012 17:57

Alex Mising name

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

Ed Willink

Messages: 7655
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'
> );
> }

Report message to a moderator

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:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 20 03:10:53 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter