[Pharo-dev] about SortFunctions

Thierry Goubier thierry.goubier at gmail.com
Tue Nov 7 08:27:29 EST 2017


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

> 2017-11-07 13:50 GMT+01:00 Thierry Goubier <thierry.goubier at gmail.com>:
>
>>
>> 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
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171107/6ca71281/attachment-0002.html>


More information about the Pharo-dev mailing list