Sorry if my "fix" disrupted you Andreas, I guess I fixed the wrong thing. But while Dictionary's appear able to contain nil keys afterall, what about WeakKeyDictionarys? As their keys are garbage-collected and converted to nil it would be unpredictable, at best.
Therefore, what do you think of my overriding #associationsDo: in WeakKeyDictionary, which was the real crux of my original fix back in June of '04? I should have just stopped with this..
associationsDo: aBlock "Evaluate aBlock for each of the receiver's elements (key/value associations)."
super associationsDo: [ : eachAssoc | | eachKey | eachKey _ eachAssoc key. "reference to ensure no GC" eachKey ifNotNil: [ aBlock value: eachAssoc ] ]
I've run with this since that time without any problem, but even better with expert feedback.
Incidentally, there may be a few special side-effects to having a nil key in a regular Dictionary which could bite at some point. For example:
(Dictionary new at: nil put: 'nil') keys
Regards, Chris
Chris Muller wrote:
Sorry if my "fix" disrupted you Andreas, I guess I fixed the wrong thing. But while Dictionary's appear able to contain nil keys afterall, what about WeakKeyDictionarys? As their keys are garbage-collected and converted to nil it would be unpredictable, at best.
Agreed, yet I could still see some reasons to do it. I think the key question is: What exactly are you trying to fix? There was some mentioning of "dictionaries cannot have nil keys" but no argument has ever been made why this should be so. It's like saying Arrays cannot contain "0" - what would be the point of that? ;-)
Also, I think it's well-understood that users of weak dictionaries may get some unpredictable behavior as the keys may go away at any time. If you use a weak key dictionary you really should understand that this may happen and guard appropriately. If that's not doable, then maybe we should stop having those be (subclasses of) collections and make them something completely different.
Therefore, what do you think of my overriding #associationsDo: in WeakKeyDictionary, which was the real crux of my original fix back in June of '04? I should have just stopped with this..
But then again, what for? What is actually broken? I still haven't seen anything that could be considered a bug.
Incidentally, there may be a few special side-effects to having a nil key in a regular Dictionary which could bite at some point. For example:
(Dictionary new at: nil put: 'nil') keys
That's an interesting point. The best cure would probably to fix sets so they can contain nil entries.
Cheers, - Andreas
Just a thought, asking a dictionary for its keys will give an error if there is a nil key since Sets "cannot meaningfully contain nil"!
Oops, missed the end of the last message. A big deal to change sets to allow nils though!
Chris Muller wrote: [snip]
Therefore, what do you think of my overriding #associationsDo: in WeakKeyDictionary, which was the real crux of my original fix back in June of '04? I should have just stopped with this..
associationsDo: aBlock "Evaluate aBlock for each of the receiver's elements (key/value associations)."
super associationsDo: [ : eachAssoc | | eachKey | eachKey _ eachAssoc key. "reference to ensure no GC" eachKey ifNotNil: [ aBlock value: eachAssoc ] ]
Well, I was quite disturbed to find out that: 1. #associationsDo: does not process all of the associations in the dictionary. That's what the message asks for, not all non-nil-key associations. 2. Finalization was completely broken by this change.
I've run with this since that time without any problem, but even better with expert feedback.
Funny, I would have guessed that a lack of any finalization would affect the functioning of something like Magma....
Daniel
Well, I was quite disturbed to find out that:
- #associationsDo: does not process all of the associations in the
dictionary. That's what the message asks for, not all non-nil-key associations.
The whole premise of my question was asking whether nil keys should be allowed in WeakKeyDictionary's. If not, then "all" would imply "all non-nil" keys.
Its a worthy question because special conditions arise out of allowing nil keys. For example, since when does any Dictionary report multiple entries at the same key when using keysAndValuesDo: and then report "key not found" when using at: for that key?
|d| d := WeakKeyDictionary new at: 'hello' copy put: 'abc' ; at: 'world' copy put: 'def' ; yourself. Smalltalk garbageCollect. d keysAndValuesDo: [ : k : v | Transcript cr; show: k printString, v printString ] d at: nil
I think this clearly demonstrates that nil is not just another key; it's special. Since my work in other Smalltalks did not allow nil keys in Dictionary's, I had assumed it was a bug. Since I was wrong, I apologize. I now ask for your help and clarification.
- Finalization was completely broken by this change.
Really? That is disturbing.
Funny, I would have guessed that a lack of any finalization would affect the functioning of something like Magma....
Not sure since I don't ever override #finalize. No finalization issues have been reported to me regarding the use of Magma. However, it has been noticed WeakKeyDictionary's grow tremendously before Squeak clears out the nil keys, encouraging the user to explicitly #finalizeValues themselves occasionally.. Is this due to finalization being broken?
Regards, Chris
Thanks chris since this is the question I was aksing myself.
Stef
On 20 sept. 05, at 07:40, Chris Muller wrote:
Sorry if my "fix" disrupted you Andreas, I guess I fixed the wrong thing. But while Dictionary's appear able to contain nil keys afterall, what about WeakKeyDictionarys? As their keys are garbage-collected and converted to nil it would be unpredictable, at best.
Therefore, what do you think of my overriding #associationsDo: in WeakKeyDictionary, which was the real crux of my original fix back in June of '04? I should have just stopped with this..
associationsDo: aBlock "Evaluate aBlock for each of the receiver's elements (key/value associations)."
super associationsDo: [ : eachAssoc | | eachKey | eachKey _ eachAssoc key. "reference to ensure no GC" eachKey ifNotNil: [ aBlock value: eachAssoc ] ]I've run with this since that time without any problem, but even better with expert feedback.
Incidentally, there may be a few special side-effects to having a nil key in a regular Dictionary which could bite at some point. For example:
(Dictionary new at: nil put: 'nil') keys
Regards, Chris
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Chris Muller -
Daniel Vainsencher -
Gary Chambers -
stéphane ducasse