Re: Redefined "=" = generic disaster?

[Lao Xiao Hai <laoxhai@ix.netcom.com>]

Robert Dewar wrote:

> In article <39FCEFAD.56BE85B1@ix.netcom.com>,
>   Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:
> > Could not resist posting this package specification and body
> > in response to your challenge Robert.
>
> OK, you posted the code. My request was to post code that did
> something other than what you would expect from reading the
> code. I can't see that this is true, but then I am not
> telepathic, I cannot guess what peculiar expectations you
> might have.
>
> Please explain why this code does something different from
> what you expect?

As I recall, the discussion had something to do with unreliable
expectations with regard to overloading the equality operator.
It is true that someone reading my example would have no
particular expectation.   It is also true that your selection of
the word "peculiar" to describe the example is appropriate.

The point of the posting is that one can certainly overload the
equality operator in strange ways and those can be coded so
as to obfuscate any reasonable meaning.    It is a short step
from there to obfuscation of the intended meaning.   Sadly,
there are those among us (mostly in the C++ world, I suppose),
who seem to delight in obfuscated code.  In other cases, someone
does it thoughtlessly.   Just today, someone showed me a package
specification in which he had overloaded the equality operator for
a generic formal record parameter.   What he intended the equality
operator to do and what one might have reasonably expected were
far from the same.  I suggested the following, to coincide with his
intentions.

Instead of,

          function "=" (L, R : Item) return Boolean;

he needed,

         function Key_Is_Equal(L, R : Item) return Boolean;

With this operation, any user knows what to expect of the contract.
That is often not the case with overloading of the "=" by itself.

Richard Riehle