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