On Wed, Dec 23, 2009 at 1:45 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2009/12/23 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Apparently sort: is not understood by SortedCollection :( And sortBlock: is not understood by ArrayedCollection subclasses :( So this is cool OrderedCollection does not understand sort:
Could we dare to fix that? Does anybody have a solution?
Stef
ArrayedCollection>>sort: aSortBlock     "Sort this array using aSortBlock. The block should take two arguments     and return true if the first element should preceed the second one."
    self         mergeSortFrom: 1         to: self size         by: aSortBlock
SortedCollection>>sortBlock: aBlock     "Answer an instance of me such that its elements are sorted according to     the criterion specified in aBlock."
    ^(super new: 10) sortBlock: aBlock
Oh that one bugs me... You also have
asSortedArray asSortedCollection asSortedCollection: sortBy:
A bit too many selectors?
The different semantics currently are: - sort in place  - #sort and #sort: - make a sorted copy - #asSortedArray does except if already isMemberOf: Array and isSorted, #sortBy: does too but is only understood by SequenceableCollection (stupid) - make a sorted collection that can further sort added elements - #asSortedCollection #asSortedCollection: #sortBlock: has 2 semantics: instance creation and modifying the sort block of an instance...
And I would like another message to avoid all these keys asArray sort I spreaded in trunk: - sort in place if possible (if Sequenceable), or create a sorted sequence otherwise But you can understand I did not dare adding a new selector :)
Funnily I just spent last week with John O'Keefe looking at non-VASt-compatible protocol that Seaside uses, comparing it across platforms, and pondering which pieces to include tests for in Grease and which to stop using in Seaside. (by the way, he was happy to add a whole bunch of "useful" protocol to their base image, which is great news). I need to write a summary of everything we came up with as well over the holidays, but in the meantime, here's what we came up with around sorting: #sortBlock: is defined by ANSI on SortedCollection as an accessor and an instance creation method. That's what it sounds like and shouldn't be implemented on non-sorted collections. #asSortedCollection is defined by ANSI on Collection and returns an instance of SortedCollection. #sort and #sort: -- Squeak/Pharo have it on ArrayedCollection, VW has it on SequenceableCollection, and VASt will now add it. This sorts the instance in place. #sorted, #sorted: -- VW already has this. VA is adding it. Squeak/Pharo should add it, IMO, but we'll add it to Grease if not. It returns a sorted copy of SequenceableCollections and a sorted Array of all other collections. #sortBy: is silly, as you mention and not supported on any other platform. We're adding it to our lint rules as a "do not use" method. We didn't notice #asSortedArray but I think that's a terrible name -- the pattern with #as* methods is that the thing after the "as" should be a class. That behaviour could be easily achieved with "aCollection sorted asArray" or "aCollection asArray sort" if really needed. So that's what VASt/Seaside/Grease are doing... I encourage you to follow our lead. :) Julian