I think sortfunctions are a great tool, with particular benefits if you use it in the context of metamodels, like with Magritte descriptions.
Also I think it is more readable to use symbols/sortfunctions than blocks. The only thing that should be guarded in the use of SortFunctions is the handling of nil, a comparison with a nil object should fail noisily, which currently doesn't by default AFAIR (I added the option to put nils first or last in the resulting collection). Note: Being myself an stubborn early optimizer I would make that `SortedCollection new` returns a sorted collection with itself as the default sortblock implementing #value:value: in SortedCollection. This saves you from instantiating new objects other than the collection itself for instances where sortblock is based on #<= as it currently is. Regards, On 25/04/2018 09:08, Denis Kudriashov wrote: > Hi. > > Now we have really nice SortFunction's machinery. We can simply write: > > Object allSubclasses sorted: #name ascending > > instead of: > > Object allSubclasses sorted: [:a :b | a name <= b name ]. > > And there is special kind of SortFunction which represent such block > itself: > > > [:a :b | a name <= b name ] asSortFunction "==> a > CollatorBlockFunction". > > > The power of first class functions is that they provide reusable > composition features like: > > > contacts sorted: #name ascending, #surname descending. > contacts sorted: (#name ascending, #surname descending) reversed. > > > (look at class comments for more examples). > > It is all very cool and powerful but in the core Pharo still work with > primitive blocks. > All sorting methods and SortedCollection are implemented in terms of > sortBlock. > So SortFunction's are adopted to block interface #value:value:. > > And my proposal: > Let's replace sortBlock by sortFunction everywhere. Block will still > work but it will be converted to function. > It will open new possibilities to implement more features. > For example SortedCollection>>reversed would be trivial with > sortFunction (see previous thread). > > Drawback is extra dependency in collections. But we can extract > SortedCollection and related functions into separate package which > probably will allow reduce bootstrapped codebase. > > I am not going to implement it right now. Just want to share this idea > to see what's wrong with it. > > Best regards, > Denis -- Esteban A. Maringolo
