[BUG][FIX] WeakKeyDictionary>>keysAndValuesDo:

Richard A. O'Keefe ok at cs.otago.ac.nz
Fri Jun 18 04:55:40 UTC 2004

I wrote:
	>[these 14 classes]  They actually provide a beautiful example 
	>of why Martin Wirblat's code snippet provides misleading answers.  
	>ReadWriteStream *does* define #= (and #hash) so as to compare states 
	>(same position and same contents).  This contributes 10 classes to 

Martin Wirblat <sql.mawi at t-link.de> wrote:
	this is actually a "beautiful example" of your ability to not only 
	find all arguments which are supporting you, but to find some which 
	are supporting the other side and make them look (at the first glance) 
	as if it were the other way round.

No, it's called honesty.  Your code snippet, as a way of addressing the
question, *IS* deeply flawed, and it so happens that one of the flaws
is in your favour.  The other flaws are not, of course.

	Additionally you come up with many 
	facts which only have a loose connection to the core of the problem 

I spent a couple of hours on that message.  I didn't spend my time in idle
insult, but took the question "what is the rareness of definitions of #=
in Squeak *really* evidence of" seriously.  If you don't see the strength
of the connections, that's really not my problem.

	Sometimes I have the impression that you are trying to disprove
	the validity of use of every single word, instead of trying to
	understand what their originator wanted to express.
How can I possibly tell what you wanted to express except by looking
at what you wrote?  You have yet to provide a substantive example of
something that should work in Squeak but doesn't, which might
possibly have given me a clue.  (I don't count anything that can trivially
be fixed by using IdentitySet instead as a 'substantive' example.  What's
needed is an example where some of the elements of a set *should* be
compared using their states, so Set must be used instead of IdentitySet,
but the Sets amongst them *shouldn't*.  That would be a very strange example.)

	I was really interested why _you_ didn't stumble - as I did -
	about no (changing) Set in another Set, but it is hard to
	communicate with you this way.
As the immortal Casey said in T. S. Eliot's poem,
"You gotta use words when you talk to me".

Let's take this last question very seriously.  My answer may look
dismissive, but I offer it with all the earnestness I possess.

How come I "didn't stumble about no (changing) Set in another Set"?

I read a book.

Specifically, I read the classic "Smalltalk-80" books.  (Unfortunately,
two of them have "walked" and so has volume one of "Inside Smalltalk".)
The description of Object made the distinction between #= and #== very
clear, also the distinction between #hash and #identityHash.  The
description of the collection classes made it quite clear that you DON'T
use mutable objects as elements of Sets or keys of Dictionaries unless
you are very sure that their state will not change while they're in there.
Sets depend on equality.  Equality depends (or may depend) on state.
Mutation changes state.  Therefore DON'T mutate things in sets.  It's simple,
it's obvious, it's in textbooks.
In fact, I've used a lot of collection libraries in a lot of languages;
I once wrote a large collection library in Pascal making heavy use of M4
to (sort-of) simulate Ada generics.  It's pretty much language-independent:
putting mutable objects in sets is dangerous.  Here's part of the Javadoc
for java.util.Set:
 Note: Great care must be exercised if mutable objects are used as set
 elements.  The behavior of a set is not specified if the value of an object
 is changed in a manner that affects equals comparisons while the object is
 an element in the set.  A special case of this prohibition is that it is
 not permissible for a set to contain itself as an element.   [[SUN]]

Oh yeah, a VisualWorks manual I happen to have lying around (never did
install the program, don't even have the operating system any more) says

    "One collection is equal (-) to another collection if it is the same
     type of collection, has the same number of elements, and all of the
     elements are equal. ...
     Testing for identity (==) determines whether two collections are
     the same object.  While this is a very fast test, it is seldom used
     since two distinct collections will fail the test even if they are of
     the same type, have the samer number of elements, and all of their
     elements are the same."

The wording could have been better, but there is no restriction there to
sequences; the Collections chapter calls Sets and Bags and Dictionaries
collections too.

More information about the Squeak-dev mailing list