Dear Squeakers,

currently (2.7) we have
	'foo' = #foo -> true
	#foo = 'foo' -> false
.
Last suggestions of me and Dan ensure symmetry for comparison of Symbols
and Strings, but not ANSI compliance.
Symmetry is a must, IMNSHO. What about ANSI compliance?

I think this is a serious compatibility problem, not just an academic
discussion.


To make String and Symbol ANSI compliant
========================================

First variant:
------------------

(1) make
	'foo' = #foo -> false
(symmetry leads to same result for #foo = 'foo' automagically then) by

- changing SequenceableCollection>>= to be conformant to protocol
<sequencedReadableCollection>,
- removing #= from String (semantically, means it has to be the same
result as SequenceableCollection>>=).

Both changes were suggested by Richard.


(2) check code for all potential (!) occurences of the case
	'foo' = #foo
(true so far, but not after ANSI) then and rework it -> difficult for
vars!



Second variant:
-------------------

Changing the ANSI standard: it is a draft! Or is it official now?
		
==================================


Do we want to have ANSI compliance at all?
Do we want to have ANSI compliance here?

Any comments?

Stephan


=================================
The standard

NCITS J20 DRAFT December, 1997 of ANSI Smalltalk Standard revision 1.9

says for 
5.7.8 Protocol: <sequencedReadableCollection>
...

5.7.8.2 Message Refinement: = 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. Answer true if the receiver is equivalent to
comparand. Otherwise answer
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. Conformant
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. However, only
objects whose implementation of #= is temporally invariant can be
reliably stored within collections
that use #= to discriminate objects.

Refinement: <sequenceReadableCollection>

Unless specifically refined, the receiver and operand are equivalent if
all of the following are true:
1. The receiver and operand are instances of the same class.
2. They answer the same value for the #size message.
3. For all indices of the receiver, the element in the receiver at a
given index is equivalent to the
element in operand at the same index.

Element lookup is defined by the #at: message for the receiver and
operand.
Parameters
comparand <Object> uncaptured
Return Values
<boolean> unspecified
Errors
none

=================================

Note: There isn't a refinement of #= in protocol <readableString>. I'm
assuming that introducing (by a refinement) a contradiction to the
parent protocol <sequencedReadableCollection> here, wouldn't be allowed.


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3