On Tue, Oct 20, 2009 at 1:49 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

>
> 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?
>

You're in the clear.  Here's the relevant screed from my draft standard:

*Protocol: <abstractDictionary XE "abstractDictionary" >*

*Conforms To*

<collection>

*Description*

Provides protocol for accessing, adding, removing, and iterating over the *
elements* of an unordered collection whose *elements* are accessed using an
explicitly assigned external *key*.

*Glossary Entries*

*Messages*

addAll:

at:

at:ifAbsent:

at:ifAbsentPut:

at:put:

*collect:*

includesKey:

keyAtValue:

keyAtValue:ifAbsent:

keys

keysAndValuesDo:

*keysDo:*

*reject:*

removeAllKeys:

removeAllKeys:ifAbsent:

removeKey:

removeKey:ifAbsent:

*select:*

values

...

*Message: keys*

*Synopsis*

Answer a collection of *keys* at which there is an *element* stored in the
receiver.

*Definition: <abstractDictionary>*

Answer a collection of all the *keys* in the receiver.  The size of the
result is equal to the size of the receiver.

*Return Values*

<collection> unspecified

*Errors*

none

...

There are also places where the standard explicitly denotes something as *
unspecified.* Most notably, the protocol section allows an
*unspecified*return value. The specifics of such features are not
defined by the standard
although some reasonable behavior is required.  Conforming implementation
must support the feature but need not documented the details of the
implementation.

A Smalltalk program conforms to the standard if it only makes use of
features defined in the standard. It may use
*implementation-defined*features or
*unspecified* features and still be considered a conforming program, though
doing so may limit the program's portability.


> - Bert -
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091020/226c4b86/attachment.htm