> The solution to a #hashING problem should not depend on our taste (like or
> dislike), since sometimes it is a non-trivial theoretical problem. So the
> question is: is there any definition of the #hash method that is known to be
> satisfactory in the general (average) case? When the answer is negative for
> a given class, one should avoid using objects of that class as keys in
> Dictionaries (or use them with special care).

Both solutions presented satisfy the hashing invariant, so both are
both are correct. The differences in performence depend on "typical"
usage patterns.  By "like", I meant my perception of typical usage of
sets in a hashing context.  

I'm more curious how many of you out there care about EXPLICITLY representing
the functional-nature/immutability of various objects (be they Sets, Strings,
or whatever).

I.e. Something like:

S := (String new: 1).
S isImmutable       =>  false
S at: 1 put: $Q.
(Set with: S)       => error: 'element is mutable'
S becomeImmutable.
S at: 1 put: $Q.    => error: 'attempt to modify an immutable object'
S isImmutable       => true
(Set with: S)       => Set ('Q')
'literal string' isImmutable   => true

I, personally, have mixed feelings about stuff like this.
On one hand, it appeals to me on a theoretical basis.  In fact, I run
with modifications that do what I described, above.  On the otherhand,
in two years of using the system, it has only given me the 

	error: 'attempt to modify an immutable object'
	
once (not counting testing, of course).  In fact, It had been so long since
I put the system in place, I'd forgotten what the error meant, at first.
The offending code was somebody elses, and it was correct code, but I
consider modifying strings that are method literals as poor taste.

On the other hand, even though I like the mechanism, theoretically, since
it doesn't seem to prevent errors that arise by seasoned programmers, in
practice, I wonder whether the mechanism is worth it's "weight".

Opinions?

-- Mike Klein