# Re: equality

From: Thomas Baar (baar@ira.uka.de)
Date: Mon 24 Nov 2003 - 13:46:45 GMT

```Dear Tim,

the equality symbol = you refer to (p. 6-3) is the declared for the OCL
type OclAny. Since Integer and Real
are subtypes of OclAny, you can compare with = also integers and reals,
i.e. 1 = 1 or 1 = 1.0 are syntactically correct
expressions on OCL.

In order to decide, whether 1=1 is evaluated to true or false you have
to consult Section A.2 (the informal
explanation '"x = y" evaluates to true if x is the same object as y' may
confuse, since we are speaking
here about data rather than objects).

In A.2.1 you find, that the data type Integer is always interpreted by
the set of integers plus the bottom symbol
for undefinedness  ( I(Integer) = \semint \uni \{\bottom\}) and the data
type Real by the set of reals plus the bottom
(I(Real) = \semreal \uni \{\bottom\})
(To express it more in the programmer's way: I(Integer) and I(Real) are
the data which are available during
execution time of a program. In that respect they are similar to the
objects I(c) of a class c.
The main difference between data and instances is that the set of data
can never change (one cannot
create/ destroy data). Furthermore, data are unique, i.e. you cannot
find two elements in I(Integer)
with the same value (e.g. value one (denoted here as \semone)).)

After that introduction we come back to your question whether 1=1 is
evaluated to true or false.
The literal 1 is always evaluated to its corresponding value in
I(Integer) \semone (see A-10 last paragraph)
and the equation symbol = is always evaluated to the identity relation
in the semantic domain (here I(Integer),
see A.2.2). So, we have to answer the question whether \semone is
identical to \semone and the answer
is simply 'yes, this is true'.

The argumentation for 1=1.0 is similar. Bear in mind, that the data type
Integer is a subtype of Real and thus
I(Integer) is a subset of I(Real). Since there is only one element in
I(Real) representing the value
one, this must be the same element \semone we have already used above.
Consequently, the literal 1.0 is evaluated to \semone as well and 1=1.0
is evaluated to true.

As you see, this is very similar to the primitive types as realized in Java.

********************

There is no predefined support in OCL to handle integer as objects of
classes. But, of course, one
can for instance define a class MyInt with attribute val of type Integer.

As for any other classes, different objects of MyInt (i.e. their
identities are distinct from each other)
may have the same value for attribute val,
so we could find a snapshot where the following constraint is evaluated
to true:

MyInt.allInstances()->exists(mi1, mi2| not(mi1 = mi2) and mi1.val = mi2.val)

The query equals(arg:MyInt):Boolean in class MyInt you have in mind
could be specified as follows:

context MyInt inv:
MyInt.allInstances->forAll(arg|
self.equals(arg) = (self.val = arg.val))

To my knowledge, there is no standardized support in OCL for additional
queries as 'equals'
(one could imagine to have them added by default to every class in the
user's class model...)

Best regards,

Thomas Baar

Tim Klinger wrote:

>
> Hello all,
>
> I am a bit confused/concerned about the semantics of equality in OCL2.
>  The spec (1/6/2003) says (p. 6-3) that an expression like "x = y"
> evaluates to true if x is the same object as y.  For one thing, this
> is dependent on the mapping of symbols to objects which is not
> specified anywhere I've seen.  For example, if I implement the
> evaluation by creating a new object for each integer literal I
> encounter then "1 = 1" will be false according to this definition.
>  Regardless, it doesn't seem natural for the primitive types --
> something like "1 = 1.0" will evaluate to false.  The java semantics
> for primitive types seems more intuitive.  Also, for non-primitive
> objects, object identity is often not a very useful measure of
> equality.  Maybe it would be better would be to require the evaluation
> to use an "equals" method on the types if it one were available and
> default to object identity if not.  I noticed a proposal in the
> finalization process to add equality for collection types; object
> identity will not be very useful in that case either.
>