sr at evolgo.de
Thu Jun 10 15:20:27 UTC 2004
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
> 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')?
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
More information about the Squeak-dev