SortedCollection based on SortFunction [Re: SortedCollection>>reverse answers an inconsistent object]

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