[mdt-ocl.dev] Equality

[Axel Uhl <eclipse@xxxxxxxxxxxxxxxxxx>]

Hi,

following a discussion I had with Ed during EclipseCon, I looked at the 
equality implementations of numerical data types in Java and OCL. Here 
are a few first results:

Java:
-----

System.out.println((double) 1.0 == (int) 1); // --> true
System.out.println(1l == 1);                 // --> true
System.out.println(new Integer(1).equals(new Double(1.0))); // -->false
System.out.println(BigInteger.valueOf(1).equals(new Integer(1))); // 
-->false
Set<Number> s1 = new HashSet<Number>();
Set<Number> s2 = new HashSet<Number>();
s1.add(1);
s2.add(1.0);
System.out.println(s1.equals(s2)); // -->false


The corresponding comparisons in OCLEcore:
------------------------------------------

1.0 = 1   --> true
Set{1.0} = Set{1}   --> false

Additionally, OCL has this:

1=1.0000000001       --> false
1=1.0000000000000001 --> true

which I find somewhat surprising.

We can therefore at least say that there is a similar anomaly in OCL 
when it comes to numerical types in collections like we see it in Java.

This adds to the question of to which degree OCLEcore should mimic 
Java/Ecore default behavior versus complying to the letters of the OCL 
specification. We see a similar discussion in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=339952 where we can 
observe different dynamic dispatch behavior for OCL and Java.

In my opinion, OCLEcore should stay close to the Java/Ecore semantics to 
avoid confusion for the most common use cases. For 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=339952 my opinion is 
obvious as I raised the bug :-). For the numerical issues, I fear this 
discussion, in the face of backward compatibility, may open pandora's 
box. Not sure we can/should change the existing implementation at this 
point regarding its handling of numerical values.

I'm curious for your opinions.

Best,
-- Axel