NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/object/4640

Internet Message Format | 1992-12-22 | 5.2 KB

Path: sparky!uunet!gatech!darwin.sura.net!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!sun-barr!sh.wide!wnoc-tyo-news!etl.go.jp!ume!crimson!kekux!s.u-tokyo!is.s.u-tokyo!jeff
From: [e-mail] (Jeff McAffer)
Newsgroups: comp.object
Subject: Re: Equality
Message-ID: <[e-mail]>
Date: 22 Dec 92 15:20:18 GMT
References: <[e-mail]>
Sender: [e-mail] (Usenet News System)
Reply-To: [e-mail]
Organization: University of Tokyo / Object Technology International
Lines: 108

In article <[e-mail]> [e-mail] (Dave Griffith) writes:

 >So just what exactly do you all mean when you say "equality"?

For me, equality means that two equal objects can be pretty much
interchanged.  They are "essentially the same".  This means that they
should have the same protocol/bahaviour but need not be of the same
class or have a common superclass.

 >1) Equality should be reflexive.
 >      I thought this was obvious, but IEEE754 may provide a counterexample.
 >
 >2) Equality should be symettric.
 >3) Equality should be transitive.
 >4) Substitution of equals for equals should give equals.
 >5) If two objects are equal at one point in program execution, they should be
 >     equal at all points.
 >6) Assignment should respect equality.   (Assuming no side-effects, after
 >   executing x:=a; it should be true that x=a.
 >7) If your parameter passing model is based on assignment, 6) should hold
 >   mutatis mutandi.
 >8) If two objects are equal, they should be behaviourally indistinguishable.
 >   The converse need not hold, but often will.
 >9) Two sets A,B are equal iff  for_all(x:A)there_exists(y:B) such y=x, and
 >   vice versa.

I agree with all but #5.  #9 I take the generic set meaning where the
containment function is = (equals).  There are other useful
containment functions which my result in #9 failing.

 >Given mutable objects, identity was the only practical definition I found
 >which would  support all of the above.  However, identity is not a practical
 >equality definition for all objects we wish to program with (vis, integers).
 >In these cases, if immutability holds, users may be able to define equality
 >in ways which satisfy the above, and there are good reasons to let them try.

Agreed.  Given the above, equals => identity (mutable case) or =>
immutability.

However, you asked how "we" thought of equals.  For me (prior to these
discussions), identity was the default idea of equals.  Certainly the
most applicable and safest.  It was only in cases where I could have
multiple objects which could behave similarly (read equally) that I
would define a different equals operation. It means that these two are
interchangeable BUT point #5 above does not necessarily hold because I
know that the objects may be different physical bits of memory and
thus may be changed independently.  As for immutable objects, well
typically immutability and uniqueness go hand in hand so the equals is
identity definition works just fine.

This is entirely from a programming point of view.

It does seem to be #5 that is the sticking point.  You use that point
to say that only identity is reasonable for "objects" and to get away
with saying that you can use = for "values".  Ok but that is different
from my ideas from programming and likely the source of much of the
confusion (at least mine).

Just a thought.  If you accept your definition of equality then you
could implement an equal op that whenever it returned true would
delete the argument from the system and replace it with the receiver!
Cool!

 >May two objects of different classes be equal?

Yes

 >May two objects be equal even if they don't respond to the same protocol?

No but... I have been known to in the past, define equals based on a
subset of protocol.  That is , two object can be equal if they respond
to this subset and have the other equality properties I want.  Now I
would not claim that this is good or desireable.  It just was.

 >If they respond to the same protocol but have no common superclass
 >which defines that protocol (i.e. protocol similarity is incidental)?

NO!  In general I do not find many places that I want to separate just
plain ole protocol (i.e., method name, arg count...) from the
semantics of the method.  Esssentially protocol for me includes a
detailed implementation independent description of what the method
does.  Hard to test at run time I know but darn useful when you are
programming.

 >If programmers view equality as just another binary predicate, perhaps I
 >should come up with a different name for the operation I need.  Any
 >suggestions?

Perhaps!  how about "essentiallyTheSame:" :-)

An alternate question is:  What do you call what I call "equality"?

The problem with "equals" is that in everyday life we use it for all
sorts of things that are not values and that don't come close to the
properties you outlined.  People for instance.  We say things like men
and women are equal but even if you could find two for which the
principles held, #5 would fail pretty quick.  Alas, people are just
objects.

Sorry I let some of the other thread leak in here but it was hard to
avoid.



--
--
ato de, |m        -- Santa or Satan?  Think about it.