On Mon, Nov 6, 2017 at 10:20 AM, Nicolas Cellier < [email protected]> wrote:
> > > 2017-11-06 10:51 GMT+01:00 Sven Van Caekenberghe <[email protected]>: > >> >> >> > On 6 Nov 2017, at 10:37, Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com> wrote: >> > >> > 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. >> >> You are absolutely right, but it is improving and will get better. >> >> > Nope, i don't buy the argument... > The information has simply been erased and won't reappear by operation of > wishfull thinking > Even if we later add the blame API, the information of original authors is > definitely lost. > > That was already the case at each Pharo release, the mc ancestry was reset > and it was very difficult to trace back. > 7.0 is in continuity, just with a more radical eradication. > > For Pharo, such compatibility is a drag, for me it's usefull, it's just > that we have different trade offs > It's not for complaining, but trade offs are to be made explicit and > assumed. > > > > The dark theme upsets me, especially the green on blue, I could have >> searched how to change it, but there I stopped. >> >> Then switch to the light/white theme, just one setting. >> >> > 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. >> >> I think what Denis means is, it would have been helpful to apply the >> change in Pharo. How you communicate that is less relevant, just saving the >> MC version and mailing it would already have been very helpful. >> >> IMHO. >> > > Right, I can understand that cross dialect is becoming inconvenient... > That's why I gave the .diff URL just for giving a chance to glimpse at > refactoring POC. > > Pharo still has Monticello, so it could have worked (not sure how well > without common ancestor) > The extra difficulty here is that package delimitation does not match, > SortFunction has been integrated into Collection in Squeak. > Hi, punctually about this: > Is extracting sources From .mcz and filtering in change list still > possible? (Epicea?) > Yes, in latest Pharo 6 and 7 you can file browse or drag&drop the source.st inside the .mcz to either file-in or see the code. (But no, it's not Epicea). Martin > I will try and import in Pharo. But it was not humanely possible yesterday > night. > > >> > 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 < >> [email protected]>: >> > 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 >> > >>> >> > >> >> > > >> > >> > >> > >> > >> >> >> >
