[Pharo-dev] about SortFunctions
stepharo.self at gmail.com
Mon Nov 6 16:03:18 EST 2017
On Mon, Nov 6, 2017 at 9:52 PM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2017-11-06 21:04 GMT+01:00 Stephane Ducasse <stepharo.self at 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?
>> "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
> people sorted: #name ascending undefinedFirst , #age descending
> And he started to use subclasses with the intention to enrich the library I
> 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.
> But it could be implemented with a simple composition too, with a wrapper
> for toggling direction (ReverseSortFunction), and no direction inst var at
> Less states, less inst vars, less responsibility, very small and cute
> 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
>> 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 :)
More information about the Pharo-dev