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

Reply via email to