2009/10/31 Lukas Renggli <renggli@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