2009/12/23 Julian Fitzell <[email protected]>: > On Wed, Dec 23, 2009 at 1:45 AM, Nicolas Cellier > <[email protected]> wrote: >> 2009/12/23 Stéphane Ducasse <[email protected]>: >>> 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. >
Oh, that's exactly the one I would have chosen :) We should go for it, both Squeak and Pharo. > > #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. > And in the future, change semantic as a filter before sorting like proposed here... > > 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 > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
