String/Symbol equality
Maurice Rabb
m3rabb at stono.com
Fri Sep 25 06:47:41 UTC 1998
At 10:41 AM 9/24/98, Maloney wrote:
>This issue comes up periodically. The difference results from
>the fact a Symbol wants equalit to mean "identical objects"
>whereas a String wants it to mean "collection-like objects with
>the same contents".
>
>To my way of thinking, the receiving object really *should* get
>to choose its own meaning for the "=" message, just as the
>it can decide what "+" or any other message means.
>Thus, although the asymmetry of "=" is surprising when you
>first run into it, I think it ends of making perfect sense
>when you think about it from the message passing perspective.
>
> -- John
I hear ya John, but I was reading ye old ANSI standard...
--Maurice
5.3.1.1 Message: = comparand
Synopsis
Object equivalence test.
Definition: <Object>
This message tests whether the receiver and the comparand are equivalent
objects at the time the message is processed. Return true if the receiver
is equivalent to comparand. Otherwise return false. The meaning of
"equivalent" cannot be precisely defined but the intent is that two objects
are considered equivalent if they can be used interchangeably. Conforming
protocols may choose to more precisely define the meaning of "equivalent".
The value of
receiver = comparand
is true if and only if the value of
comparand = receiver
would also be true. If the value of
receiver = comparand
is true then the receiver and comparand must have equivalent hash values.
Or more formally:
receiver = comparand Þ
receiver hash = comparand hash
The equivalence of objects need not be temporally invariant. Two
independent invocations of #= with the same receiver and operand objects
may not always yield the same results. Note that a collection that uses #=
to discriminate objects may only reliably store objects whose hash values
do not change while the objects are contained in the collection.
---------------------------------------------------------------------------
Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA
More information about the Squeak-dev
mailing list
|