2009/10/31 Lukas Renggli <reng...@gmail.com>: > 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 >
Yes, the proxy/wrapper pattern can be an elegant and efficient solution (a good example is ublas from BOOST library). It depends how many time you will iterate the collection though. Iterating a Set is often +2x the cost of iterating an Array. > 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. > Yes, an immutable proxy with copy on write behaviour is challenging to implement... > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
