Because it's a cross dialect library and because contributing in Squeak is so much easier for me.
I like the social power provided by github and i know how to use git, at least as an expert beginner. But it took me two hours to pick a pharo image, fork and clone the pharo repository, pick a pharo VM (I ended up building my own), retrieve my ssh pass phrase to avoid using github thru https, search documentation of where should I put the image wrt to my cloned git repository, search how to use iceberg, and finally realized that the author/date would not even be preserved if we want to port this cross dialect library. The dark theme upsets me, especially the green on blue, I could have searched how to change it, but there I stopped. While doing all these things, I did not spent a minute focusing on the SortFunction subject. I can see that as an investment, maybe I should have done it before, but it was too much for a Sunday evening. 2017-11-06 10:13 GMT+01:00 Denis Kudriashov <[email protected]>: > It is difficult to compare to current Pharo version. > Why you not produce Pharo pull request? > > 2017-11-06 0:06 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> I've put some of the proposed composition features into >> >> http://source.squeak.org/inbox/Collections-nice.766.mcz >> http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz >> >> http://source.squeak.org/inbox/Collections-nice.766.diff >> http://source.squeak.org/inbox/CollectionsTests-nice.283.diff >> >> SInce it's Squeak based, it uses <=>, but never mind, that's the same >> functions. >> >> >> Stephane: the original comments were from Travis Griggs. >> It's more a tutorial for using the SortFunction than a detailed >> explanation of implementation. >> >> The original idea is that oSortFunction are composable. >> For example, it's possible to chain sorting on a first criterion, then >> resort on a second criterion if objects have same rank with first. >> >> For this, we need a to distinguish when objects have same rank (=) and >> cannot use a binary result (Boolean) like legacy sortBlock, >> So we rather need a ternary comparison (<=>). >> >> This thread is about extending composition, and generalizing >> implementation by composition (like Xtreams) >> - for sorting nil first (or last) >> - for reversing the order >> - for sorting properties with any collation order, and not just default >> <=> >> >> 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <[email protected]>: >> >>> Hi guys >>> >>> Do you have some nice comments somewhere? because I do not understand >>> anything about this thread. >>> I check the code and the comments are well... unclear and confusing. >>> >>> Stef >>> >>> On Sun, Nov 5, 2017 at 4:15 PM, Nicolas Cellier >>> <[email protected]> wrote: >>> > >>> > >>> > 2017-11-05 16:06 GMT+01:00 Denis Kudriashov <[email protected]>: >>> >> >>> >> >>> >> 2017-11-05 11:33 GMT+01:00 Nicolas Cellier >>> >> <[email protected]>: >>> >>> >>> >>> >>> >>> Ah, I messed up, UndefinedSorter must not be chained, it must be a >>> >>> wrapper! >>> >>> Otherwise comparing to nil will resort to sorting by properties and >>> >>> fail... >>> >>> >>> >>> SortFunction>>undefinedFirst >>> >>> ^UndefinedSorter descending wrap: self >>> >>> >>> >>> UndefinedSorter>> collate: value1 with: value2 >>> >>> "sort all nil according to the direction (first if -1, last if >>> >>> +1), then" >>> >>> value1 ifNil: [value2 ifNil: [^0] ifNotNil: [^direction]]. >>> >>> value2 ifNil: [^direction negated]. >>> >>> ^sorterForNonNil collate: value1 with: value2 >>> >>> >>> >>> It's important to have the UndefinedSorter : >>> >>> - decoupled from property sort, because it can be generally >>> usefull >>> >>> - collating 2 nil as 0, so that another property can be chained >>> >> >>> >> >>> >> I like your idea. >>> >> It also forced me to think that direction itself should be >>> implemented as >>> >> wrapper. I would name it InvertedSortFunction: >>> >> >>> >> InvertedSortFunction>>collate: value1 with: value2 >>> >> ^(actualSortFunction collate: value1 with: value2) * -1 >>> >> >>> >> >>> >> If we will do it then direction will be not part of SortFunction. And >>> all >>> >> current functions will be in fact ascending. >>> >> And to explicitly reflect this fact I would introduce >>> >> AscendingSortFunction as their superclass. >>> >> InvertedSortFunction and ChainedSortFunction will stay subclasses of >>> >> SortFunction. >>> >> >>> >> So what you think? >>> > >>> > >>> > Yes, I was thinking the same. >>> > On another hand, direction makes thing symmetric and has its elegance >>> too. >>> > What I don't like with it is that it forces the library to have two >>> > different messages for the same thing: >>> > - collate:with: in base class accounting for direction >>> > - threeWayCompare:with: in every subclass >>> > >>> > The fact to hardcode the direction in base class could be seen as an >>> > optimization too. >>> > I'm not sure what Sista optimization could bring in this case, because >>> the >>> > selectors may get megamorphic... >>> > >>> > >>> >> >>> >>> >>> >>> >>> >>> In >>> >>> >>> >>> people sortBy: #name ascending undefinedFirst , #age descending >>> >>> >>> >>> we could then have people with name nil still sorted by age, what is >>> not >>> >>> possible with current implementation >>> >>> >>> >> >>> > >>> >>> >> >
