2017-11-07 13:37 GMT+01:00 Denis Kudriashov <[email protected]>: > > 2017-11-07 13:11 GMT+01:00 Thierry Goubier <[email protected]>: > >> 2017-11-07 12:09 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> Concerning syntactic sugar (even if it's pure Smalltalk) I have same >>> cicrconspection >>> >> In the case of #name >> #size it's like we are creating another language >>> for the basic mechanisms we already have (send messages) >>> What we try to achieve here is in fact the reify the send, what is not >>> really in the base Smalltalk. >>> For a more functional style, we would rapidly need currying anyway so >>> even more syntactic sugar... >>> >> >> Yes, that would be my worry. There is a value in keeping simple >> consistent semantics... especially because there is no one else still >> maintaining that focus (apart from STEPS that is) and that we are under >> constant pressure from other languages to add stuff. >> > > One note: we are not discussing here the possible new language or system > core feature. It should be in separate package with clear intention in the > name (like FunctionalProgramming). So it can provide nice handy message for > their domain. >
Hum, I've already seen that sort of package for Squeak. Or at least I know someone who codes like that in Squeak. > >> >>> For SortFunction, I think we all agree that there's no debate, >>> procedural style is so ugly >>> >>> people sorted: [:a :b | >>> a name >>> ifNil: >>> [ b name >>> ifNil: [a age > b age] >>> ifNotNil: [true "a first"]] >>> ifNotNil: >>> [ b name >>> ifNil: [false "b first"] >>> ifNotNil: [a name = b name >>> ifTrue: [a age > b age] >>> ifFalse: [a name < b name]]] >>> >>> compared to: >>> >>> people sorted: #name ascending undifiedFirst , #age descending >>> >>> or even >>> >>> people sorted: (#name collatedWith: #isNil) , #age descending >>> >> >> I find that exemple interesting because the obvious solution to the >> procedural style is to create a nice, correct People>>#>, which is of great >> value for the overall code understanding. So, is it a good idea to make it >> easier not to write a proper #>? >> > > It will not help because desired order depends on concrete use case. > Different reports can represent people in completely different order. > And do you think that any object should implement comparison? > No, but that hiding it into a mix of business domain specific messages mixed up with general sorting arguments somewhere at the point of sorting people is bad software design. > > >> >> 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. 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 >> >> >>> >>> >>> >> >> >
