[BUG][FIX] WeakKeyDictionary>>keysAndValuesDo:

Martin Wirblat sql.mawi at t-link.de
Tue Jun 15 08:29:09 UTC 2004

"Richard A. O'Keefe" wrote:
>Remember the fundamental rule about #hash:
>    x = y implies: x hash = y hash


>Now, suppose we have two different Set objects x, y, which have the
>same elements:
>    x := #(1 2 3 4) asSet.
>    y := #(3 1 4 2 4 1 3) asSet.
>We expect that x = y.  After all, two sets are equal if and only if 
>they have equal elements, and if Sets don't act like sets, they have 
>no right to the name.  If we *ever* hope to use Sets as elements of 
>other Sets or as keys in a Dictionary, they had *better* get equality 
I guess you are referring with "the name" to how mathematicians have 
defined their Sets. They have platonic Sets, meaning = and == are not 
distinguished. Here on earth representation or materialization 
matters, so programmers can have different sets with the same contents.

Programmers' Sets are different from mathematicians'. A mathematician 
can't add something to a set without getting another set. After 
adding something to a set a programmer has of course the same object 
and that may lead him to think that he has the same set. 


>	For me it is totally nonintuitive not to be able 
>	to put any Set into another one.
>No, you've got it wrong.  What I said was that you cannot put a Set
>object inside ITSELF.  You can put a Set inside a DIFFERENT set with
>no trouble at all.  In fact, from what you have said, out of Ambrai,
>Dolphin, VSE, VW, and Squeak, Squeak is the *only* one where you *can*
>usefully put a Set inside another Set.
I know what you said. But you are implying that a set is the Set of 
the mathematicians. Only then you can put a set into another set. Such 
a Set must not be changed, which contradicts to the programmer's day 
to day use of Set. 
>	In fact every object that is explicitly designed to change its
>	contents but which is not maintaining its hash value will give
>	the programmer no intuitive clue that it can't be put in a Set.
>I am always suspicious of appeals to 'intuition'.  One can reasonably
>expect a Smalltalk programmer to know the two fundamental rules of 
>(1) x = y implies: x hash = y hash
>(2) A mutable object should not be mutated while its hash value is 
>    that is, while it is a member of a set or bag or a key in a 
>    dictionary. 
That may be clear to you, but I bet that many if not most people who 
are programming Smalltalk (i.e. including many newcomers) are not 
aware of this problem, which is pretty good demonstrated by the fact 
that different Smalltalk dialects implement Sets differently (and only 
Squeak gets it right in your opinion). 

After all one criterion for the quality of a programming language is 
how intuitive it is. A Set and even more a Bag is a brown sack for me. 
I stuff things in it and from time to time I ask if something specific 
is in it. I would be astonished when I order to put something new into 
the sack and it vanishes from the cellar of my warehouse and pops up 
in the loft. 

Arrays and Strings can be created literally and can not change size. 
There is a difference to Sets and that's what I wanted to express with 
"explicitly designed to change". Arrays and Strings are more alike the 
mathematician's Set than the programmer's Set is. 

A Squeak Set implements the mathematician's equality for #=. My brown 
sack would be better suited with implementing identity for #= and 
#hash accordingly and an additional #equals: would serve the 
mathematicians. Perhaps the question is, if the average programmer is 
more a mathematician or a warehouse worker? 


More information about the Squeak-dev mailing list