[Pharo-dev] about SortFunctions

Denis Kudriashov dionisiydk at gmail.com
Tue Nov 7 07:37:22 EST 2017


2017-11-07 13:11 GMT+01:00 Thierry Goubier <thierry.goubier at 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.


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


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


>
> 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
>
>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171107/7b9e4321/attachment-0002.html>


More information about the Pharo-dev mailing list