Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Equality


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:


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>();
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 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 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.

-- Axel

Back to the top