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. > > 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 >>> >>> >>>> >>>> >>>> >>> >>> >> >
