In st-80, the keys did answer a Set and the values a Bag, with no obvious
mapping between these two order-wise.
In Squeak, there were historically a fasterKeys that did answer an Array in
order to avoid the overhead of testing uniqueness of keys and to avoid
rehashing the keys...
Then we decided to simplify everything by answering an Array for both keys
and values with the guaranty that (self at: (self keys at: i)) == (self
values at: i) for any i from 1 to keys size...
But it's just a conveniency, it was not intended to be generalized...
Also, keep in mind that the order may change at any time with the mutations
of the Dictionary...




2014-11-27 2:23 GMT+01:00 Florin Mateoc <florin.mateoc at gmail.com>:

> On 11/26/2014 7:14 PM, Levente Uzonyi wrote:
> > Your example hides the problem of ordering - what Tobias is asking about
> - so here's another:
> >
> > (IdentitySet withAll: #(1 1.0)) collect: [ :each | each class ]
> >
> > If IdentitySet >> #collect: were returning an Array, then what would be
> the answer?
> >
> > { SmallInteger. Float } or { Float. SmallInteger } ?
> snip
> > Levente
>
>
> Then why does Dictionary>>keys return an Array? Where does the order come
> from in that example?
> Similarly, where does the order come from when you invoke collect:as: on a
> set with Array as an argument?
> The answer is quite simple: it is the iteration order. collect: is part of
> the _iteration_ protocol.
>
> I agree with Frank here, for me a more important aspect of collect: is
> preserving the _mapping_ between the original
> elements and the collected values.
> There is no obvious mapping if there are fewer collected values than
> elements.
>
> Florin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141127/aca7f1b6/attachment.htm