Re: Equality operator overloading in ADA 83

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Mats said

<,I think that the argument of backward compatibility with Ada 83 is not
that important (just my opinion). I think that if someone redefines an
operator for a type, then he probably has a good reason to do so, and
that operator becomes part of the abstraction provided by that type and
must stick with it wherever the types goes, with no exception.
>>

To ignore the compatibility issue here would have been a serious mistake.

What frequently happens is that in the body, where a private type is
visible, you don't really want the redefined equality at all, but you
get it some of the time, and you have to convert etc to get rid of it,
which of course is necessary in both Ada 83 and Ada 95 code. But if
you extend the reach of this equality operator, then it will extend
into these bodies -- and that easily cause incomaptibilities of the
worst possible kind (i.e. Ada 83 code would compile fine, but give
subtly different results). 

The design process of Ada 9x was, quite properly in my view, extremely
conservative with respect to this kind of incompatibility. It was considered
to be worth while incurring some such isntances for 8-bit characters (which
in legal terms were allowed in Ada 83 anyway), but certainly not for
tagged types.

I must say that I here a lot of sturm und drang with respect to this issue
(equality not composing), but I must say I have never found this a 
limitation in real code. Array and record equality is rare in any case,
and is even rarer in cases where component equality has been redefined.