so that we can have a discussion in the list:
I recently carried this change in trunk (many commits).
Context: traditionally st80 #keys answers a Set and #values answers a Bag, because both keys and values are unordered in a Dictionary.
Squeak (and Pharo) #keys answer a Set, but #values answers with an Array.
This has some advantages: 1) no code does expect a Bag specific protocol 2) most code won't need to #add: to nor #remove: from values. (this is not possible to perform these operations on an Array) 3) creating and iterating an Array is much faster than a Bag, because no indirection, nor hash/lookup: is necessary, and no iteration on empty slots is necessary (a Set or Bag necessarily have empty slots).
It happens that the same can be applied to #keys, because very few senders are using a Set specific protocol. I did analyze this in the trunk image.
There was already a #fasterKeys for that purpose that can happily be cancelled.
Drawbacks: 1) break compatibility with a few external packages (that just a matter of adding asSet here and there, and this solution is inter dialect compatible). 2) changes might span across lot of packages (exagerated in trunk because I adpoted then retracted #fasterKeys... I did not dare breaking compatibility without Andreas agreement)
Advantages: 1) make #keys consistent with #values (same order, same class) 2) optimize code without complexifying the code
Delete commentComment 1 by nicolas.cellier.aka.nice, Today (11 hours ago) The same "optimization" can be applied on #selectors, and this is related to this subject because #selectors is defined in term of ^methodDict keys On Oct 21, 2009, at 11:15 PM, Nicolas Cellier wrote:
I made a proposal here: http://code.google.com/p/pharo/issues/detail?id=1353
feel free to comment about it
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project