2009/10/20 Bert Freudenberg <bert at freudenbergs.de>:
>
> On 20.10.2009, at 06:54, Andreas Raab wrote:
>
>> Hi Nicolas -
>>
>> I agree with your (original) reasoning that keys should return an array
>> just like values. Not only because of performance, but also because it
>> preserves ordering between keys and values making "aDict keys with: aDict
>> values do:" nicely symmetrical to "aDict keysAndValuesDo:".
>>
>> Nicolas Cellier wrote:
>>>
>>> So I gave it a try with a bunch of commits
>>> (ouch, commiting is longer than editing!)
>>> I used #fasterKeys because the message already exist.
>>> I cannot change keys directly, a few senders really expect a Set (plus
>>> external packages...)
>>
>> Which ones are those? I do dislike the idea of using fasterKeys. It's a
>> bad name (like using #valuesWithOrder instead of #values) and unless the
>> difficulties with the change are systematic (i.e., usage patterns that are
>> not easily detected and lead to hidden and hard to find issues) I would much
>> rather see this fixed than worked around.
>>
>> Can you provide some examples of places that break?
>>
>> Cheers,
>>  - Andreas
>
> Yes, #fasterKeys is ugly. I'd rather replace the places that need a Set with
> "keys asSet". Unless ANSI says differently - could someone check?
>
> - Bert -
>

That's what it will turn into...
OK, I realize we should better attack the problem under this angle:
1) modify senders expecting a Set keys -> keys asSet
2) change keys implentation -> faster keys implementation

I can do this this evening, unless there is another taker

Nicolas