With an eye to producing a new version of SortedCollection, I spent a couple of hours yesterday going through all of the methods in SortedCollection + all those inherited from OrderedCollection + all those inherited from Collection.
Like other core collection classes, SortedCollection turns out to be, um, less than robust and less than consistent.
My current "favourite" is this:
s := #(1 2 4) asSortedCollection. s collect: [:x | x] ==> an OrderedCollection(1 2 4) s with: s collect: [:x :y | x] ==> a SortedCollection(1 2 4)
Surely they should return the same kind of object!
This is the underlying reason why
s := #(1) asSortedCollection. s + 1 ==> an OrderedCollection(2) s + #(1) ==> a SortedCollection(2)
which leads to #(1 2 3) asSortedCollection + #(-2 -4 -6) ==> a SortedCollection(-1 -2 -3) which is in fact NOT sorted (it has a nil sortBlock).
The simplest solution would seem to be to make #with:collect: also return an OrderedCollection.
Not to making it a holy grail, but
Richard A. O'Keefe wrote:
With an eye to producing a new version of SortedCollection, I spent a couple of hours yesterday going through all of the methods in SortedCollection + all those inherited from OrderedCollection
- all those inherited from Collection.
Like other core collection classes, SortedCollection turns out to be, um, less than robust and less than consistent.
My current "favourite" is this:
s := #(1 2 4) asSortedCollection. s collect: [:x | x]
==> an OrderedCollection(1 2 4) s with: s collect: [:x :y | x] ==> a SortedCollection(1 2 4)
with:collect: isn't covered by the standard (draft v1.9).
I'm beginning to like it ;-)
And about SortedCollection>>collect: it says:
NCITS J20 DRAFT December, 1997 215 of ANSI Smalltalk Standard revision 1.9
5.7.17.4 Message Refinement: collect: transformer
Synopsis Answer a new collection constructed by gathering the results of evaluating transformer with each element of the receiver. Definition: <collection> For each element of the receiver, transformer is evaluated with the element as the parameter. The results of these evaluations are collected into a new collection. The elements are traversed in the order specified by the #do: message for the receiver. Unless specifically refined, this message is defined to answer an objects conforming to the same protocol as the receiver. Refinement: <SortedCollection> Answer a <sequencedCollection>. Parameters transformer <monadicValuable> uncaptured Return Values <sequencedCollection> new Errors If the elements of the receiver are inappropriate for use as arguments to transformer. If the result of evaluating the transformer is inappropriate for storage in the collection to be returned.
For <SortedCollections> the standard wants to have a <sequencedCollection>, which may be one of (or conforming to for <string>) <OrderedCollection>, <Array>, <ByteArray> or <string>.
Surely they should return the same kind of object!
This is the underlying reason why
s := #(1) asSortedCollection. s + 1
==> an OrderedCollection(2) s + #(1) ==> a SortedCollection(2)
which leads to #(1 2 3) asSortedCollection + #(-2 -4 -6) ==> a SortedCollection(-1 -2 -3) which is in fact NOT sorted (it has a nil sortBlock).
The simplest solution would seem to be to make #with:collect: also return an OrderedCollection.
Sounds reasonable.
Greetings,
Stephan
squeak-dev@lists.squeakfoundation.org