Haven't made the change yet. Up to my own devices, I would
ensure that a string and a symbol are never equivalent.
This would be consistent with VisualWorks and VSE.
I can't easily check other dialects at this moment, but
I suspect that most others follow the fold.

I would be quite surprised if any code "depended" upon
asymmetric behavior of equivalence. That leaves code
that depends upon strings and symbols occasionally being
equivalent... let's just say I wouldn't want code like
that deployed in any mission critical applications...

Conclusion: a string and a symbol should never be equivalent
Proposed Solution: redefine #= in String to exclude equivalence
with Symbols.

anybody think I missed the boat here?

John S
[ | ] knight of the curly brace face ;-}>


> From: Bijan Parsia <bparsia at email.unc.edu>
> Reply-To: squeak at cs.uiuc.edu
> Date: Wed, 5 Apr 2000 17:53:28 -0400 (EDT)
> To: squeak <squeak at cs.uiuc.edu>
> Subject: Re: [BUG] equivalence between strings and symbols
> Resent-From: squeak at cs.uiuc.edu
> Resent-Date: 5 Apr 2000 21:54:16 -0000
> 
> On Wed, 5 Apr 2000, John W. Sarkela wrote:
>> working with Squeak 2.7 we discovered the following situation
>> 
>> #squeak = 'squeak' false
>> 'squeak' = #squeak true
>> 
>> mathematics defines equivalence as a relation that is
>> 1. reflexive
>> 2. symmetric
>> 3. transitive
>> 
>> Well, the above just ain't symmetric.
> 
> Thanks because, in this situation #= doesn't represent equivalence!
> 
> In keeping with the proposals to Pythonize Squeak's syntax, #= has been
> redefined to denote "sorta not assignment", and, as everyone knows Symbols
> are very picky about their assignments (they have to watch their image
> after all), where as a String will give enough of itself to hang you!
> 
> No, I'm just kidding. Fixing this seems like a good idea, but I worry a
> touch about breakage of stuff which "accidentally" depends on this
> behvaior. I'm not speaking entirely hypothetically, as I seem to recall
> difficulty with nil, 'nil', and #nil in some package I was porting (alas,
> I can't recal the details).
> 
> Have you mad eyour proposed change? Did anything obvious break?
> 
> Cheers,
> Bijan Parsia.
>