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