2017-11-07 13:59 GMT+01:00 Denis Kudriashov <[email protected]>: > 2017-11-07 13:50 GMT+01:00 Thierry Goubier <[email protected]>: > >> >> 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 >>>> >>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >
