[Pharo-dev] About Collator

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Nov 5 18:32:26 EST 2017


2017-11-05 20:11 GMT+01:00 Denis Kudriashov <dionisiydk at gmail.com>:

>
> 2017-11-05 18:41 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>> As for -1 , 0 , 1, we must encode 3 possible results:
>>
>> value1 is before value2 (<)
>> value1 is same rank as value2 (=)
>> value1 is after value2 (>)
>>
>
> While it is well known comparison logic I would like to find better name
> than #compare/collate which reflects explicitly what you just described.
> Something like:
>
> sortFunction rank: anObject1 comparedTo: anObject2
>
>  And according to this the current #threeWayCompareTo: can be renamed too:
>
> anObject rankComparedTo: anObject2
>
>
> Another idea is to have explicit meaning in the method name that it
> defines ascending order of receiver compared to argument. I am always
> confused when I need to implement a new block for sorted collection. I am
> usually not know what result I will have: will it be ascending or
> descending. Because block itself has no meaning about it and it only
> returns true or false. Same confusion could happen during implementation of
> new #threeWayCompareTo: method.
> So I would use something like:
>
> anObject rankInAscendingOrderTo: anObject2
>
>
> Maybe it is bad in english. But I hope it shows my idea. So if you like
> it, try suggest better names.
>
>
Denis, you already know my opinion, but if you insist on a new selector,
then I'm proposing

<,=,> anObject
    "Answer the direction for collating self and anObject.
     The direction is
     -1 is self is to be collated to the left (self < anObject)
     0 if self and anObject have same rank (self = anObject)
     1 if self is to be collated to the right (self > anObject)"

...snip...



>> Using numbers -1,0,+1 to encode these results is clever, because it's
>> trivial to revert the order (just take the opposite, or multiply by -1)
>> So it's widespread in programming community, it's cultural
>>
>> We could use any other convention like Symbols #(< = >), that would
>> convey a bit more meaning,
>> but there's no need to go against culture if we have no superior solution
>> (wrt inversion)
>>
>> 2017-11-05 18:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.com>:
>>
>>> Hi Stef
>>>
>>> Collation is the accurate and correct term
>>> If I google: Unicode comparison algorithm for example, the first hit is:
>>> UTS #10: Unicode Collation Algorithm - Unicode.org
>>> http://unicode.org/reports/tr10/
>>>
>>> collationner (collate) has a second meaning, even in French:
>>> https://fr.wiktionary.org/wiki/collationner
>>>
>>> Interestingly, the wikipedia page https://en.wikipedia.org/wiki/
>>> Collation isn't even translated in French...
>>> Maybe i's not popular enough in French (un mot savant)...
>>> I'm not good enough in English to tell if it has same "snob" connotation
>>>
>>> Nicolas
>>>
>>> 2017-11-05 17:49 GMT+01:00 Stephane Ducasse <stepharo.self at gmail.com>:
>>>
>>>> Hi nicolas
>>>>
>>>> where it is defined that collation is something returning -1, 0, 1?
>>>> I'm always thinking to newcomers that have to learn yet another
>>>> concept and here for nothing.
>>>> Because SortFunction with a nice comment saying that it should return
>>>> -1, 0, 1 looks simpler that CollatorFunction which tells me nothing,
>>>> except that may be this is about drinking (for french).
>>>>
>>>>
>>>> Stef
>>>>
>>>> On Sun, Nov 5, 2017 at 3:47 PM, Nicolas Cellier
>>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> >
>>>> >
>>>> > 2017-11-05 10:16 GMT+01:00 Esteban Lorenzano <estebanlm at gmail.com>:
>>>> >>
>>>> >>
>>>> >>
>>>> >> > On 5 Nov 2017, at 06:00, Stephane Ducasse <stepharo.self at 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
>>>> >> >
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171106/5a0fc021/attachment-0002.html>


More information about the Pharo-dev mailing list