[news.eclipse.modeling.mdt.ocl] Re: Expressions involving undefined valu

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Adrian

Yes, not being able to type an empty Collection has caught me out too.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=288569 raised to remind me 
to raise an OMG issue one day to allow OrderedSet(EClass){}.

I don't understand your parser exception on

OrderedSet{}->first()

It parses fine. It just evaluates incorrectly to a Java null rather than
an OCL invalid. https://bugs.eclipse.org/bugs/show_bug.cgi?id=288566 raised.

	Regards

		Ed Willink

Adrian Price wrote:
> Hi Ed,
>
> Many thanks for the response and detailed explanation. I myself had found 
> the OCL spec. rather confusing as to the semantics of undefined / invalid / 
> null and your proposed revisions offer some reassurance that it wasn't just 
> me being slow on the uptake.
>
> I'm putting together a JUnit test case to illustrate the problems I've seen, 
> will post to here and Bugzilla when complete. BTW the JUnit is not so 
> straightforward since OCL does not have a syntax for declaring an empty 
> explicitly typed collection literal. For example (using classes from the 
> Ecore package for convenience) none of: OrderedSet(EClass)->first(), 
> OrderedSet(EClass){}->first(), OrderedSet()->first() or 
> OrderedSet{}->first() appear to be valid OCL. BTW the production 
> CollectionLiteralExpCS ::= CollectionTypeIdentifierCS '{' 
> CollectionLiteralPartsCS? '}' permits an empty element list but for the 
> fourth example in the previous sentence MDT/OCL throws the parser exception 
> "Argument is null, expected a List".
>
> Thanks & regards,
>
> Adrian.
>
> "Ed Willink" <ed@xxxxxxxxxxxxx> wrote in message 
> news:h7mk2f$p27$1@xxxxxxxxxxxxxxxxxxxx
> > Hi Adrian
> >
> > The OCL 2.0 specification was never consistenly updated to redefine the 
> > 'undefined' value as the 'null' and the 'invalid' functionality. Most
> > of the MDT-OCL behaviour can be justified by one of the many contradictory 
> > statements in the specification; though NPEs can never be right. Please 
> > submit your example as a Bugzilla and we'll fix it.
> >
> > I posted a substantive revised text to resolve 'null' and 'invalid' as 
> > http://www.omg.org/issues/ocl2-rtf#Issue14197. We are working to have an 
> > unambiguous specification and an implementation compliant with it.
> >
> > The corresponding rationalisation of invalid/Invalid/OclInvalid was
> > applied to CVS HEAD yesterday as part of 
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=282882.
> >
> > We are currently resolving a variety of areas where the treatment of
> > null and invalid is not quite right.
> >
> > Issue 14197 is our best guess at what is correct and we might have
> > it implemented by M3 or perhaps M4.
> >
> > For now I'm afraid you just need to do excess empirical testing.
> >
> > Regards
> >
> > Ed Willink
> >
> >
> > Adrian Price wrote:
> > > Good day mdt.ocl,
> > >
> > > Many of our OCL constraints involve complex chained expressions 
> > > referencing modelled features and query operations, any part of which 
> > > could be undefined.
> > >
> > > According to "OCL 2.0 Specification  ptc/2005-06-06" Paragraph 7.4.11 (?) 
> > > "Undefined Values":
> > > "Some expressions will, when evaluated, have an undefined value. For 
> > > instance, typecasting with oclAsType() to a type that the object does not 
> > > support or getting the ->first() element of an empty collection will 
> > > result in undefined. In general, an expression where one of the parts is 
> > > undefined will itself be undefined..." However, in practice I see 
> > > NullPointerExceptions when such expressions are evaluated. For example:
> > >
> > > inv inParamControlDisabled: let opposite : Bindable = 
> > > getInboundValueBinding()->first().getOppositeEndpoint(self).target in 
> > > enabled.value and opposite.oclIsKindOf(Parameter) implies 
> > > opposite.oclAsType(Parameter).inout <> InOutType::IN
> > >
> > > throws NPE if getInboundValueBinding() returns an empty list, apparently 
> > > as a result of attempting to using Java reflection APIs to invoke the 
> > > getOppositeEndpoint() method on a null reference. At present the only way 
> > > around this is to make the OCL expressions self-null-checking, which 
> > > obviously makes them more complicated than the spec. suggests they need 
> > > be, less readily comprehensible and (presumably) less performant.
> > >
> > > Is my understanding of the OCL spec. flawed or is this a bug?
> > >
> > > Thanks in advance,
> > >
> > > Adrian Price
> > > Senior Architect
> > > TIBCO Software, Inc.