> 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
>>
[hidden email]
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project>
Locked
