Watch out, because code like this may or may not work: someDictionary keys do: [:each | each isNotInteresting ifTrue: [someDictionary removeKey: each]] Thus, I think keys should answer a new collection. If the intent is to iterate over the keys, then I'd send the message directly to the dictionary. Andres. Lukas Renggli wrote:
It always annoyed me that #keys and #values create a new collection object. Form an object-oriented stand-point of view, what would rather make sense is to return a collection that delegates to the dictionary.
For example, DictionaryKeys would be a subclass of Collection, behave like a Set and be implemented along ...
Dictionary>>keys ^ DictionaryKeys on: self
DictionaryKeys>>do: aBlock dictionary keysDo: aBlock
DictionaryKeys>>includes: anObject ^ dictionary includesKey: anObject
DictionaryKeys>>species ^ Set
I bet that this would not only result in a major performance improvement, but also greatly reduce memory consumption. Furthermore it would solve the problem that #keys suddenly has totally different performance characteristics as we decide to return an Array instead of a Set. For example, it wouldn't matter anymore if you wrote
aDictionary includesKey: #foo
or
aDictionary keys includes: #foo
I see only obvious problem for such an approach and this is when the dictionary changes and the keys are stored somewhere. Some users might not expect the keys to change too.
Cheers, Lukas