From: greg@afs.com (Gregory H. Anderson)
Subject: Re: Equality
Reply-To: greg@afs.com
Date: Thu, 24 Dec 1992 18:37:08 GMT

In article <1992Dec22.152021.4209@kei.is.s.u-tokyo.ac.jp>  
jeff@is.s.u-tokyo.ac.jp (Jeff McAffer) writes:

> > May two objects of different classes be equal?
> 
> Yes

Please explain how that could be. Just because they happen to be exactly  
the same size, and happen to involve exactly the same instance variables,  
which happen to contain the same values, are two objects from different  
classes equal? In Objective-C, this would be prima facie impossible,  
because the first instance variable is always 'isa', which points to the  
class. If two objects were equal in the sense I just defined, they would  
*have* to be members of the same class, or else their 'isa' pointer would  
be different. Maybe I'm missing something?

Also, I would argue that an object is more than the sum and contents of  
its ivars. I would expect 'equal' objects to respond to the same methods,  
so I could use them interchangeably. Otherwise, something doesn't feel  
right to me about the definition of equality. I guess I'm arguing that  
both attributes and functional capabilities must be accounted for in  
deciding the equality of objects.

> > 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.
> 

You just agreed with my last point, but in a less strict way. Even a  
minimal subclass that involves new methods only is different, and I would  
argue that these differences make its instances non-equal.

> > 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.
> 

No, but for a different reason. Aside from my 'isa' pointer objection  
above, if two objects come down through two different hierarchies, then  
even a common set of ivars and methods don't make them equal, because they  
will potentially respond in different ways. In other words, there is no  
greater likelihood they will act the same way as any two unrelated classes  
that happen to implement the same method. If the action is not the same,  
then the objects are not equal, even if their ivars and method namespaces  
superficially resemble each other.

--
Gregory H. Anderson          | Thus spake the master programmer: 
Master Programmer / Manager  | "Let the programmers be many and  
Anderson Financial Systems   | the managers few; then all will be 
greg@afs.com  (Nextmail OK)  | productive." -- Tao of Programming
Newsgroups: comp.lang.eiffel,comp.compilers