[BUG] equivalence between strings and symbols

John W. Sarkela john_sarkela at 4thEstate.com
Mon Apr 10 17:27:54 UTC 2000


Originally I thought along your lines, Lex. Then I actually read
the ANSI spec. It suggests that collections of differing class
should never be equal. If the behavior must change (I believe it must)
there had better be strongly compelling reasons to go against
standard behavior.

Given the standard I believe that either #= in SequenceableCollection
should check for class equality rather than species equality or else
redefine #= in String to preclude asymmetry when compared to symbols.

[ | ] John Sarkela  :-}>

> From: "Lex Spoon" <lex at cc.gatech.edu>
> Reply-To: squeak at cs.uiuc.edu
> Date: Mon, 10 Apr 2000 10:01:01
> To: squeak at cs.uiuc.edu
> Subject: Re: [BUG] equivalence between strings and symbols
> Resent-From: squeak at cs.uiuc.edu
> Resent-Date: 10 Apr 2000 15:30:12 -0000
> 
> "John W. Sarkela" <john_sarkela at 4thEstate.com> wrote:
>> Conclusion: a string and a symbol should never be equivalent
>> Proposed Solution: redefine #= in String to exclude equivalence
>> with Symbols.
>> 
> 
> 
> Man, everyone quietl agrees that a symbol "obviously" can't be
> equal to a string.  However, consider this implementation:
> 
> Symbol>>= anObject
> self class == anObject class ifTrue: [
> ^self == anObject ].
> ^super = anObject
> 
> This implementation allows #abc = 'abc', but the performance should
> still be very good when comparing two symbols.
> 
> I kinda like #abc = 'abc'.  I doubt anyone will be terribly surprised by
> this, any more than they are surprised by 2.0 = 2.  Furthermore, Symbols
> and Strings are mostly supposed to be the same; it's just that Symbols
> are faster at certain things--why not keep their behavior
> as similar as possible?
> 
> 
> 
> Lex
> 





More information about the Squeak-dev mailing list