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 > > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
