Are null-able Enums still supported?https://www.eclipse.org/forums/index.php/mv/msg/297291/805602/#msg_805602
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

]]>Alex Mising name2012-02-24T00:00:37-00:00Re: Are null-able Enums still supported?https://www.eclipse.org/forums/index.php/mv/msg/297291/805941/#msg_805941
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]]>Ed Willink2012-02-24T10:18:09-00:00Re: Are null-able Enums still supported?https://www.eclipse.org/forums/index.php/mv/msg/297291/806213/#msg_806213
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: