Re: [mdt-ocl.dev] Question regarding numeric types

[Axel Uhl <eclipse@xxxxxxxxxxxxxxxxxx>]

Ed,

I agree with the value semantics part. That's not a problem with 
EMF/Java semantics because Java collections don't compare by identity of 
the Java primitive wrappers but by equality. So the "this 3 != that 3" 
doesn't cause problems.

The OCL conformance of Integer to Real is really a pain in the neck from 
the Java perspective, probably the specification of the type Real as 
such: "The standard type Real represents the mathematical concept of 
real." I can always write an expression

	let r:Real=1.0/3.0 in r*3

and hope to get back 1.0. But how realistic is that in practice? Even 
one step further:

	let r:Real=1.0/3.0 in 1=r*3

How likely is it that all OCL implementations will solidly return true 
in this case? This seems a very unreliable operation except for writing 
is as documentation next to some model (which I care less about than I 
do care about executable specifications).

Also, from an EMF perspective, the int 3 == double 3.0 doesn't matter so 
much because I'm not aware of an EMF case where this type of comparison 
collapses the two values. All collections in Java are Object-typed, 
therefore will use the wrappers.

The potential inconsistency between an EMF x.many_feature.size() and a 
corresponding OCL x.many_feature->size() is pretty irritating.

Best,
-- Axel

On 4/18/2011 3:16 PM, Willink, Ed wrote:
> Hi Axel
>
> Interesting observation.
>
> Pedantically, OCL 2.0, 2.2, 2.3 has no explicit numeric equality semantics.
> Just:
>
> "OCLAny
> =(object2 : OclAny) : Boolean
> True if self is the same object as object2. Infix operator.
> post: result = (self = object2)"
>
> which does not require that this 3 is equal to that 3.
>
> --------------------------------------------------------------------
>
> IMVHO OCL is primarily a specification language and so should be highly
> implementation-independent; although I'm not convinced that million-digit
> precision is totally necessary or practical for division.
>
> OCL should support libraries so migration should be an issue.
>
> ---------------------------------------------------------------------
>
> OCL cannot just adopt Java semantics because Java has three different
> semantics for two different equalities
>
> value-semantics: int 3 == double 3.0
> object-semantics: Integer 3 != Double 3.0, and this Integer 3 != that
> Integer 3
> object-value-semantics: Integer 3 !.equals Double 3.0, but this Integer 3
> .equals that Integer 3
>
> ---------------------------------------------------------------------
>
> OCL does have Integer to Real conformance which strongly suggests that if
>
> this Real 3 = that Real 3, then this Real = that Integer 3
>
> I think that anything other than value-semantics for OCL numerics is almost
> untenable.
>
> ----------------------------------------------------------------------
>
> The EMF anomally is embarrassing, but can be worked around by ensuring
> the the EMF UniqueEList is assessed for OCL uniqueness when creating a
> corresponding SetValue. This should lead to no inconsistency, any access
> within OCL should see the collapsed collection.
>
> In order to be more EMF-friendly, the EMF OCL Standard Library which must
> anyway
> define the mapping of Etypes to OCL primitives can define its own variant
> equality
> semantics.
>
> NB. With a modelled library, equality is defined by the library not by OCL.
>
> [I haven't got the code to hand, but I suspect that SetValue is already
> collapsing a collection, using polymorphic Value equality, which is
> currently
> built-in. It's one of a number of areas that can be more model driven.]
>
> 	Regards
>
> 		Ed
>
> > -----Original Message-----
> > From: mdt-ocl.dev-bounces@xxxxxxxxxxx
> > [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
> > Sent: 18 April 2011 13:09
> > To: MDT OCL mailing list
> > Subject: [mdt-ocl.dev] Question regarding numeric types
> >
> > Ed, all,
> >
> > I'm wondering how OCL semantics for numeric types interferes
> > with Java's
> > definition. We had this discussion before. But here's a
> > thought that I
> > think hasn't been brought forward yet.
> >
> > If we integrate OCL with Ecore/EMF then on the EMF side there are
> > collection types and their constraints, derived from the Ecore
> > multiplicity settings. For example, there is UniqueEList. It's
> > add/contains is based on regular Java equality.
> >
> > With this, an EObject many-feature that is modeled as unique
> > can easily
> > hold EDoubleObject and EIntegerObject values that are not equal
> > according to Java semantics but will be equal according to
> > standard OCL
> > semantics. If an OCL PropertyCallExp accesses such a feature, an
> > inconsistent OCL collection will result, inconsistent in one
> > of two ways:
> >
> >    - if OCL chooses to collapse values equal to each other
> > according to
> > OCL semantics, the property's cardinality will differ from the EMF
> > feature's cardinality
> >
> >    - if OCL leaves the values distinct according to Java semantics in
> > place, the collection is inconsistent from OCL's point of
> > view because
> > it should be unique but has two distinct values equal
> > according to OCL
> > semantics.
> >
> >   From an EMF/Ecore perspective, the most pragmatic way out of this
> > dilemma seems to be to alter OCL semantics such that they comply with
> > Java semantics. In particular, this would make 3.0<>  3 which
> > might come
> > as a shock to the OCL purist but would probably be fairly
> > intuitive to
> > Java/EMF/Ecore consumers.
> >
> > The implications, of course, are horrible in another sense. OCL
> > expressions would not be entirely portable across
> > environments. But: is
> > this a dominant use case? What would it look like? How would I obtain
> > and re-use a significant body of OCL-implemented libraries in
> > a platform
> > context different from the one where it was developed?
> >
> > Best,
> > -- Axel
> > _______________________________________________
> > mdt-ocl.dev mailing list
> > mdt-ocl.dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>
> Please consider the environment before printing a hard copy of this
> e-mail.
>
> The information contained in this e-mail is confidential. It is intended
> only for the stated addressee(s) and access to it by any other person is
> unauthorised. If you are not an addressee, you must not disclose, copy,
> circulate or in any other way use or rely on the information contained in
> this e-mail. Such unauthorised use may be unlawful. If you have received
> this e-mail in error, please inform us immediately on +44 (0)118 986 8601
> and delete it and all copies from your system.
>
> Thales Research and Technology (UK) Limited. A company registered in
> England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne
> Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number:
> 774298
>
> Thales UK Limited. A company registered in England and Wales. Registered
> Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
> Weybridge, Surrey KT15 2NX. Registered Number: 868273
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev