2017-11-07 14:40 GMT+01:00 Nicolas Cellier < [email protected]>:
> > > 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:. > > > 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 >>> >>> >> >
