2017-11-07 14:45 GMT+01:00 Denis Kudriashov <[email protected]>: > 2017-11-07 14:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-11-07 14:20 GMT+01:00 Denis Kudriashov <[email protected]>: >> >>> I have new question. Why we really need threeWayCompareTo:? >>> DefaultSortFunction can implement it using standard comparison methods. >>> >>> >> But what would the DefaultSortFunction use? >> 2 among the 3 selectors < = > ? >> It's just that we might scan String twice when <=> would do it once, but >> apart that is OK >> > > Yes, you are right. > And we already have VM based String compare: with strange logic returning > 1, 2, 3. So we already can optimize current String>>threeWayCompareTo:. >
Maybe good idea to open ticket and modify image level methods to return standard -1,0,1 values. > > >> >> >> 2017-11-05 0:37 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >>> l.com>: >>> >>>> Hi all, >>>> I started a discussion with Denis in a pull request >>>> https://github.com/pharo-project/pharo/pull/430 >>>> But since it's going beyond simple code review, it probably has a >>>> better place here. >>>> >>>> First, I want to say thanks for enriching this original work of Travis >>>> Griggs. >>>> http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html >>>> http://objology.blogspot.fr/2010/11/tag-sortfunctions.html >>>> <http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html> >>>> >>>> Of course, I'm never satisfied. >>>> So I don't really appreciate the rewrite of space ship operator <=> >>>> into a more heavy threeWayCompareTo: >>>> >>>> In my eyes, it's so obvious that <=> means < or = or > in the context >>>> of SortFunction >>>> And also that the order matches the signs >>>> < = > >>>> -1 0 1 >>>> IOW result will be -1 if receiver is <, 0 if equal, +1 if superior >>>> >>>> #threeWayCompareTo: does not tell as well. >>>> But maybe It's a question of taste and I don't have the same eyes as >>>> Pharo people? >>>> To me it's also a question of respect to the original author, don't >>>> change a good selector for the sake of changing. >>>> >>>> Apart this detail, I wanted to speak about SortByPropertyFunction. >>>> SortByProperty is super usefull for composing / chaining like this: >>>> >>>> population sortBy: #name ascending , #age descending. >>>> >>>> But currently, SortByPropertyFunction is allways using the default >>>> hardcoded collation <=> ... He he, it's also notice it's shorter to write >>>> ;) >>>> >>>> Imagine that my properties are neither String nor Magnitude, or they >>>> are, but I want a different collation policy, because in French $é must not >>>> be sorted too far from $e. >>>> >>>> It could be written quite simply with: >>>> >>>> c sortBy: #name collatedInFrench ascending , #age descending >>>> >>>> With current implementation, collatedInFrench would have to use a block >>>> (thru a CollatorBlockFunction which is a proxy to the block in a >>>> SortFunction disguise): >>>> >>>> Symbol>>collatedInFrench >>>> "interpret self as a property" >>>> ^[:a :b | FrenchCollator collate: (self value: a) with: (self >>>> value: b)] >>>> >>>> But IMO SortByPropertyFunction should better feed a reified >>>> CollatorFunction, or said differently a SortFunction, as Denis said. >>>> >>>> Symbol>>collatedInFrench >>>> ^FrenchCollator new onProperty: self >>>> >>>> SortFunction>>onProperty: aValuable >>>> ^SortByPropertyFunction sortProperty: aValuable with: self >>>> >>>> What do you think? >>>> >>>> Nicolas >>>> >>>> >>> >> >
