Lex Spoon wrote:
> Two comments.
> 
> First, the reason Set's cannot contain nil is because nil is used
> internally as a placeholder.  This is a bad thing IMHO and it would be
> better to allow nil.  At any rate, since dictionaries always use
> assocations in the non-empty slots, then hey do not have the same
> problem Set's do and so it would seem reasonable that they can have nil
> as a key.  (Though, alas, this means that the current #keys method runs
> into problems.  Ack!)  I'd prefer that we move in the direction of
> supporting nil in dictionary's and set's, because there is no
> fundamental problem with it.  (Set could have an instance variable
> holdsNil that specifies whether nil is in the set!

> Or, Set's could use
> a different place holder than nil; they could do "Object new" to create
> a unique placeholder object.)

Seems to be a good idea to me. First I've thought of taking "self" as
the placeholder, but then the Set couldn't contain itself...

> 
> Second, on the issue of WeakKeyDictionary keys, note that the keys are
> held by weak references.  Thus, are you certain that in this code from
> your changeset that the key will not disappear between the check for nil
> and the evaluation of the block?
> 
> 	super associationsDo: [ : eachAssoc | eachAssoc key ifNotNil: [ aBlock
> value:
> eachAssoc ] ]
> 
> If ifNotNil: has been inlined, then I would think the block might lose
> access to the key.  You could test this by having a key that becomes
> garbage, then call associationsDo:, and then have aBlock run a garbage
> collection as the first thing it does.  Anyway, it seems safer to make a
> hard reference to the key just to be sure, something like:
> 
> 	:eachAssoc | 
> 	| key |
> 	key _ eachAssoc key.
> 	key ifNotNil: [ aBlock value: eachAssoc ]
> 	
> Now, the "key" variable will keep the key from disappearing until aBlock
> is through evaluating.

This sounds good, but: are you sure?
I'm quiet confident, that this is correct for the actual Squeak, but:
wouldn't it be possible for a clever system to throw away (gc) variable
"key" after the #ifNotNil: check? The evaluation of the block doesn't
need "key". Are you sure, that this behavior is forbidden by some
specification (not to say 'standard')?


Greetings
Stephan

> 
> 
> 
> -Lex
> 
> 

-- 
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