November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about SortFunctions

by Sven Van Caekenberghe

> On 7 Nov 2017, at 01:21, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Back to the thread: https://github.com/pharo-project/pharo/pull/440 Thx! > 2017-11-06 22:52 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > On Tue, Nov 7, 2017 at 4:52 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > MC is not so bad. OK branches are not named (or neeed not be), GUID are inferior to SHA, etc... > The biggest difference comes from github, that is the social environment, not necessarily git. > > Some would say it was github that "made" git (popular). > > cheers -ben > >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

I have other ideas yet. The selector undefinedFirst is good, but the implementation not so. I don't like the UndefinedSortFunction: too specific, compose oddly... In the PR, collatedBy: is the way to tell how we sort properties (if you have a better name, go, it's bikesheding day) "sort by size of name" (people sorted: (#name collatedBy: #size)) = (people sorted: [:p| p name size]) If we defined <=> in Boolean (orWhatEverTheLongSelectorYouPreferBecausePharoHasTheFreedomToHaveOwnTaste:) in order to have true sorted first, then we can generalize. "sort by absolute value, but put the negative first" numbers sorted: #negative sortedFirst, #abs "sort by name, but put the undefined last" people sorted: (#name collatedBy: #isNil sortedLast) , #name. sortedFirst in this case would be a synonym for ascending (or asSortFunction). Alternatively, if we don't want <=> in Boolean because it's not natural (the fact that we need a synonym is a clue) then we can have sortedFirst answering a specialized BooleanSortFunction. 2017-11-07 1:21 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Back to the thread: https://github.com/pharo-project/pharo/pull/440 > > 2017-11-06 22:52 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >> >> On Tue, Nov 7, 2017 at 4:52 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> >>>> MC is not so bad. OK branches are not named (or neeed not be), GUID are >>> inferior to SHA, etc... >>> The biggest difference comes from github, that is the social >>> environment, not necessarily git. >>> >> >> Some would say it was github that "made" git (popular). >> >> cheers -ben >> >> >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

Back to the thread: https://github.com/pharo-project/pharo/pull/440 2017-11-06 22:52 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > On Tue, Nov 7, 2017 at 4:52 AM, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > >> >>> MC is not so bad. OK branches are not named (or neeed not be), GUID are >> inferior to SHA, etc... >> The biggest difference comes from github, that is the social environment, >> not necessarily git. >> > > Some would say it was github that "made" git (popular). > > cheers -ben > >

Nov. 7, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Denis Kudriashov

2017-11-06 20:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Esteban told me that this is because he uses STON for the class definition. > Now a simple question may be we could use a string instead of a symbol > because this is strange > to have a class definitino that does not respect Pharo syntax. > But anyway we are not able to use definition from Tonel in playground. So what the difference? > > Stef > > On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: > > > > > > On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote: > >> > >> > >>> On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs@gemtalksystems. > com> > >>> wrote: > >>> > >>> > >>> > >>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: > >>>>> > >>>>> On 6 Nov 2017, at 15:43, Dale Henrichs > >>>>> <dale.henrichs(a)gemtalksystems.com> wrote: > >>>>> > >>>>> of course with Pharo's implementation of Symbol it is not practical > to > >>>>> use asString nor type checks - things that are not necessary in other > >>>>> Smalltalk implementations > >>>> > >>>> How so ? > >>>> > >>>> What is the problem with Symbol>>#asString ? > >>> > >>> I am not going to go to every field in the api that is supposed to be a > >>> String and add asString. There are too many places to worry about ... I > >>> would prefer that Pharo be ANSI compliant:) > >>> > >>> It's not just Metacello. > >>> > >>> It's an annoying issue that has to be dealt with every time a Pharo > >>> application is ported to another dialect of Smalltalk and an annoying > >>> barrier for folks running on other dialects to move their application > to > >>> Pharo - in this case the bugs that are introduced by Pharo's behavior > with > >>> respect to Symbols can be very hard to diagnose -- > >>> > >>> Making things harder to share code between dialects is a bad thing for > >>> Smalltalk overall -- just another reason for non-Smalltalk programmers > to > >>> question the whether they should use Smalltalk or not... > >>> > >>> And I don't need to hear about how Pharo is not Smalltalk:) > >>> > >>> Dale > >> > >> So there is nothing 'wrong', you just want Pharo to remain the same as > >> every other non-changing Smalltalk out there. > > > > Did I say that? > > > > I support the direction that Pharo is going, but I reserve the right to > > disagree with some of the details. > > > > This is just one detail ... nothing more nothing less ... For those of us > > that work in multiple dialects, it IS annoying and I take an opportunity > > every year or so to remind you guys of the things that I find annoying, > just > > to keep you guys honest:) > > > >> > >> From one perspective you are right, it makes some cross platform > porting > >> in either direction harder. Seaside has many rules to help portability. > Not > >> mixing Strings and Symbol is probably one of them. > > > > ... and as I mentioned, this problem can be one of the more annoying > issues > > to track down, when a developer is not careful ... Honestly there are two > > sides to the issue ... when developers use Symbols in tests to drive an > API > > that is supposed to use Strings (this happens the most often) things > break > > pretty quickly and the tests can be fixed pretty easily ... but when the > > code itself is written with mixed Symbols and Strings, the tests might > > actually pass after the port, and the bugs will only show up in subtle > cases > > ... I've hit a handful of these over the years and they are hard to track > > down... > >> > >> > >> But you know very well that Pharo was started so that we would be able > to > >> make changes, in any area or aspect of the system, without the burden of > >> backwards or cross platform compatibility, even if some of these > changes are > >> taste based. > > > > Agree with your statement -- most of the changes that Pharo has made have > > not been difficult to accommodate, but Symbol/String is at a fundamental > > level and I'm not sure that it would be "illegal" to make this > accommodation > > --- I AM pretty certain that it would cause some short term pain, but > > probably no more pain (and likely less pain) than is caused by trying to > > move an application to a new version of Pharo:) > >> > >> And I happen to like the ability to mix and match Strings and Symbols > (we > >> discussed about this before). > >> > > I won't argue with taste, it's is simply the portability for this > particular > > problem that I am highlighting ... > > > > Dale > > > >

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Ben Coman

On Tue, Nov 7, 2017 at 4:52 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> MC is not so bad. OK branches are not named (or neeed not be), GUID are > inferior to SHA, etc... > The biggest difference comes from github, that is the social environment, > not necessarily git. > Some would say it was github that "made" git (popular). cheers -ben

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Sven Van Caekenberghe

> On 6 Nov 2017, at 20:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Esteban told me that this is because he uses STON for the class definition. > Now a simple question may be we could use a string instead of a symbol > because this is strange > to have a class definitino that does not respect Pharo syntax. It might be a bit confusing at first sight, but it is correct, IMHO. It is STON syntax, not Pharo. Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but it is totally consistent with itself. STON fromString: (STON toString: #'My Strange Symbol'). STON fromString: (STON toString: #'foo-bar'). If a Symbol consists only of characters in 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then the Symbol does not need to be quoted in STON. I see no problem there. > Stef > > On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote: >>> >>> >>>> On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> >>>> wrote: >>>> >>>> >>>> >>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: >>>>>> >>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs >>>>>> <dale.henrichs(a)gemtalksystems.com> wrote: >>>>>> >>>>>> of course with Pharo's implementation of Symbol it is not practical to >>>>>> use asString nor type checks - things that are not necessary in other >>>>>> Smalltalk implementations >>>>> >>>>> How so ? >>>>> >>>>> What is the problem with Symbol>>#asString ? >>>> >>>> I am not going to go to every field in the api that is supposed to be a >>>> String and add asString. There are too many places to worry about ... I >>>> would prefer that Pharo be ANSI compliant:) >>>> >>>> It's not just Metacello. >>>> >>>> It's an annoying issue that has to be dealt with every time a Pharo >>>> application is ported to another dialect of Smalltalk and an annoying >>>> barrier for folks running on other dialects to move their application to >>>> Pharo - in this case the bugs that are introduced by Pharo's behavior with >>>> respect to Symbols can be very hard to diagnose -- >>>> >>>> Making things harder to share code between dialects is a bad thing for >>>> Smalltalk overall -- just another reason for non-Smalltalk programmers to >>>> question the whether they should use Smalltalk or not... >>>> >>>> And I don't need to hear about how Pharo is not Smalltalk:) >>>> >>>> Dale >>> >>> So there is nothing 'wrong', you just want Pharo to remain the same as >>> every other non-changing Smalltalk out there. >> >> Did I say that? >> >> I support the direction that Pharo is going, but I reserve the right to >> disagree with some of the details. >> >> This is just one detail ... nothing more nothing less ... For those of us >> that work in multiple dialects, it IS annoying and I take an opportunity >> every year or so to remind you guys of the things that I find annoying, just >> to keep you guys honest:) >> >>> >>> From one perspective you are right, it makes some cross platform porting >>> in either direction harder. Seaside has many rules to help portability. Not >>> mixing Strings and Symbol is probably one of them. >> >> ... and as I mentioned, this problem can be one of the more annoying issues >> to track down, when a developer is not careful ... Honestly there are two >> sides to the issue ... when developers use Symbols in tests to drive an API >> that is supposed to use Strings (this happens the most often) things break >> pretty quickly and the tests can be fixed pretty easily ... but when the >> code itself is written with mixed Symbols and Strings, the tests might >> actually pass after the port, and the bugs will only show up in subtle cases >> ... I've hit a handful of these over the years and they are hard to track >> down... >>> >>> >>> But you know very well that Pharo was started so that we would be able to >>> make changes, in any area or aspect of the system, without the burden of >>> backwards or cross platform compatibility, even if some of these changes are >>> taste based. >> >> Agree with your statement -- most of the changes that Pharo has made have >> not been difficult to accommodate, but Symbol/String is at a fundamental >> level and I'm not sure that it would be "illegal" to make this accommodation >> --- I AM pretty certain that it would cause some short term pain, but >> probably no more pain (and likely less pain) than is caused by trying to >> move an application to a new version of Pharo:) >>> >>> And I happen to like the ability to mix and match Strings and Symbols (we >>> discussed about this before). >>> >> I won't argue with taste, it's is simply the portability for this particular >> problem that I am highlighting ... >> >> Dale >> >

Nov. 6, 2017

Re: [Pharo-dev] browsing squeak .mcz from pharo (was about SortFunctions)

by Nicolas Cellier

2017-11-06 18:39 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > > > On Mon, Nov 6, 2017 at 10:20 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> 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 > > Thanks Martin. What is usefull is also ability to scan the diffs. Currently, having to go thru menu and open a dead diff window method after method is a no go.

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Stephane Ducasse

On Mon, Nov 6, 2017 at 9:52 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-11-06 21:04 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi nicolas >> >> While I know the ascending and other protocol, it is still unclear to >> me the composition aspect. Did Travis write a tutorial >> can we can use as documentation/comment? >> BTW >> "Example: #('abc' 'de' 'fghi') sorted: #size asscending" >> => >> >> "Example: (#('abc' 'de' 'fghi') sorted: #size) ascending >> => show the result It was about a method comment. I sent this to help you because the snippet did not work :) I'm sorry but I do not read squeak-dev since years. > Travis has just seeded the very simple and light library with chaining: > > points sorted: #x ascending , #y descending. > > Denis then added possibility to sort properties even if undefined, a common > case: > > people sorted: #name ascending undefinedFirst , #age descending > > And he started to use subclasses with the intention to enrich the library I > presume. > But current implementation does not use composition. > It adds an instance variable undefinedDirection to PropertySortFunction and > specific behavior. > What I say here is that it's easier and more powerfull to implement such > feature with composition. > > That is, sorting nil first is an elementary sort function, than can be > complemented by #name ascending, another elementary sort function. > In which case, you compose simple and little sort function with less code, > and even branchless code. > > Similarly, descending invoke toggleDirection which changes a direction inst > var in Travis' implementation. > With such implementation, every SortFunction has to care of direction inst. > var. > But it could be implemented with a simple composition too, with a wrapper > for toggling direction (ReverseSortFunction), and no direction inst var at > all. > > Less states, less inst vars, less responsibility, very small and cute > classes > The best is to read code - if I manage to both publish and answer mails ;) I really like this library this is why I pushed it to Pharo now I would like to improve the comments. >> PS: In Pharo we do not remove history of methods for the fun. >> I can tell you that I do not really like Git but I do not want our >> language to be looking like a terrible system just because it does not >> use a modern versioning control system. >> > > I don't see why it requires that mc ancestry was removed... > And mc ancestry was removed well before the git switch. Because of the size. Ask marcus because he was really concerned >> I do not expect that we will move to another versioning control system >> in the near future so we will be able to take advantage of the git >> infrastructure. >> And versioning code with resources and decent branch support will be >> game changing. >> >> > MC is not so bad. I know this is me and marcus that decided to use it to manage squeak. > OK branches are not named (or neeed not be), GUID are > inferior to SHA, etc... > The biggest difference comes from github, that is the social environment, > not necessarily git. Indeed and that people love complexity and a real distributed model. Now I do not like git (far far too complex for my taste) but I do not want to live in a museum. We will produce on top IceCube or TipTop a tool to offer the comfort of MC, because Iceberg is tooo complex (not its fault) but still I do not like all the complexity when I do not need it. And I imagine newbie (even if some people believe that newbie can master git - I do not believe this lie :) Stef

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

2017-11-06 21:04 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi nicolas > > While I know the ascending and other protocol, it is still unclear to > me the composition aspect. Did Travis write a tutorial > can we can use as documentation/comment? > > BTW > "Example: #('abc' 'de' 'fghi') sorted: #size asscending" > => > > "Example: (#('abc' 'de' 'fghi') sorted: #size) ascending > => show the result" > > Stef > Well, I willl repeat what I wrote in squeak-dev: Travis has just seeded the very simple and light library with chaining: points sorted: #x ascending , #y descending. Denis then added possibility to sort properties even if undefined, a common case: people sorted: #name ascending undefinedFirst , #age descending And he started to use subclasses with the intention to enrich the library I presume. But current implementation does not use composition. It adds an instance variable undefinedDirection to PropertySortFunction and specific behavior. What I say here is that it's easier and more powerfull to implement such feature with composition. That is, sorting nil first is an elementary sort function, than can be complemented by #name ascending, another elementary sort function. In which case, you compose simple and little sort function with less code, and even branchless code. Similarly, descending invoke toggleDirection which changes a direction inst var in Travis' implementation. With such implementation, every SortFunction has to care of direction inst. var. But it could be implemented with a simple composition too, with a wrapper for toggling direction (ReverseSortFunction), and no direction inst var at all. Less states, less inst vars, less responsibility, very small and cute classes The best is to read code - if I manage to both publish and answer mails ;) > PS: In Pharo we do not remove history of methods for the fun. > I can tell you that I do not really like Git but I do not want our > language to be looking like a terrible system just because it does not > use a modern versioning control system. > > I don't see why it requires that mc ancestry was removed... And mc ancestry was removed well before the git switch. I do not expect that we will move to another versioning control system > in the near future so we will be able to take advantage of the git > infrastructure. > And versioning code with resources and decent branch support will be > game changing. > > > MC is not so bad. OK branches are not named (or neeed not be), GUID are inferior to SHA, etc... The biggest difference comes from github, that is the social environment, not necessarily git. > > > On Mon, Nov 6, 2017 at 12:06 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 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 <stepharo.self(a)gmail.com>: > >> > >> 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 > >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > > >> > > >> > 2017-11-05 16:06 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> > >> >> > >> >> 2017-11-05 11:33 GMT+01:00 Nicolas Cellier > >> >> <nicolas.cellier.aka.nice(a)gmail.com>: > >> >>> > >> >>> > >> >>> 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 > >> >>> > >> >> > >> > > >> > > > >

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Stephane Ducasse

Hi nicolas While I know the ascending and other protocol, it is still unclear to me the composition aspect. Did Travis write a tutorial can we can use as documentation/comment? BTW "Example: #('abc' 'de' 'fghi') sorted: #size asscending" => "Example: (#('abc' 'de' 'fghi') sorted: #size) ascending => show the result" Stef PS: In Pharo we do not remove history of methods for the fun. I can tell you that I do not really like Git but I do not want our language to be looking like a terrible system just because it does not use a modern versioning control system. I do not expect that we will move to another versioning control system in the near future so we will be able to take advantage of the git infrastructure. And versioning code with resources and decent branch support will be game changing. On Mon, Nov 6, 2017 at 12:06 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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 <stepharo.self(a)gmail.com>: >> >> 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 >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > >> > >> > 2017-11-05 16:06 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> >> >> >> >> 2017-11-05 11:33 GMT+01:00 Nicolas Cellier >> >> <nicolas.cellier.aka.nice(a)gmail.com>: >> >>> >> >>> >> >>> 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 >> >>> >> >> >> > >> >

Nov. 6, 2017