On Mon, Nov 6, 2017 at 9:52 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2017-11-06 21:04 GMT+01:00 Stephane Ducasse <stepharo.self@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