2017-11-05 10:16 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:

> On 5 Nov 2017, at 06:00, Stephane Ducasse <stepharo.self@gmail.com> wrote:
>
> Hi guys
>
> Why do we rename class Sort to introduce terms that have unknown,
> unclear, undocumented meaning?

+1

>
> To me PluggableSortFunction is MUCH better than CollatorBlockFunction.

but pluggable is also bad, IMO.
also I see there is some incoherence in the names:

agree with Esteban, Pluggable pouah!

ChainedSortFunction -> this is kind of ok, but I think a ��ComposedSortFunction�� is better.

But there can be several kind of composition...

For example wrapped as illustrated with UnderfinedSorter refactoring that I proposed.

Personnally I like Chained because it explicitely tells the kind of composition

SortByPropertyFunction -> shouldn��t be ��PropertySortFunction�� ? (coherent with the previous one)

+1 for PropertySortFunction, or maybe just PropertySorter

CollatorSortFunction -> this is like a ��BlockSortFunction�� or ��ValuableSortFunction�� ?

CollatorBlockFunction is only a proxy to the block so as it answers to #threeWayCompare:with: protocol rather than value:value:

It's a Block view as a CollatorFunction.

The name first surprised me negatively, but after reflexion it tells what it is.

1) Collator indicates that the block (valuable) will return -1, 0 or +1

2) It's not necessarily a block, it could be anything understanding value:value:

But, the valuable should return -1,0,+1, so apart <=> (threeWayCompareTo:) it ain't gonna be anything but a block in practice.

For <=> we would want a DefaultSortFunction and would not use a CollatorBlockFunction.

3) Function refers to SortFunction.

For this, I'm neutral, whether you call it Sorter or SortFunction I don't care.

SortFunction kind of implies these are stateless, so it's a rather good and accurate name.

Maybe a Sorter could be more confusing, because a Sorter could be thought as having the sorted collection as instance variable (statefull).

Nicolas

Esteban

>
> Stef
>