2017-11-07 13:37 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-11-07 13:11 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:
2017-11-07 12:09 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.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
��
��
��