2017-11-07 13:59 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
2017-11-07 13:50 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:
10 years ago now, we designed a DSL above our parallel language, with the
same kind of tradeoffs you described there. We ended up discarding it, because we had to maintain the full procedural code for the cases we couldn't cover. Discarding it was a wise decision.
That's why SortFunction is now abstract class. If you want some complex logic you are able to create custom function class which will incapsulate it and make it reusable.
Then we agree: a good choice is having a proper place (sort function object, a method in simple cases) to implement that business logic if it is not obvious.
I already mentioned possible SortMethodFunction. It takes care about binary method order which should be always on top of ascending list. It would be ugly to implement it in block or with composition of selectors. And I don't think that method should define #>
On a short analysis, I could give you half a dozen valid orderings for SortMethodFunction... You've chosen one, put it as the master one, and gave it a general name 'Ordering of Methods'. You could have written it as #>, the way you're doing it.
Sorry Thierry that it is not obvious: given name is an example. Of course it is better to have explicit name.
Understood :) Thierry
Regards,
Thierry
Now, if you explained me something like that:
people nilFirst ascending
Then I'd be more convinced. Or even
people sorted nilFirst ascending (if one would prefer restricting the implementations of #nilFirst).
Could the symbol use be a smell of not putting the right responsabilities into the People class?
Thierry