[Pharo-dev] about SortFunctions

Thierry Goubier thierry.goubier at gmail.com
Tue Nov 7 06:52:38 EST 2017


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

>
>
> 2017-11-07 11:36 GMT+01:00 Thierry Goubier <thierry.goubier at gmail.com>:
>
>>
>>
>> 2017-11-07 11:24 GMT+01:00 Denis Kudriashov <dionisiydk at gmail.com>:
>>
>>>
>>> 2017-11-07 9:23 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>>> l.com>:
>>>
>>>> I have other ideas yet.
>>>>
>>>> The selector undefinedFirst is good, but the implementation not so.
>>>> I don't like the UndefinedSortFunction: too specific, compose oddly...
>>>>
>>>> In the PR, collatedBy: is the way to tell how we sort properties (if
>>>> you have a better name, go, it's bikesheding day)
>>>>
>>>>     "sort by size of name"
>>>>     (people sorted: (#name collatedBy: #size))
>>>>         =  (people sorted: [:p| p name size])
>>>>
>>>
>>> It is nice idea but it should be not bound to sort functions. Because
>>> this feature is useful for other block based messages:
>>>
>>> people collect: #name >> #size
>>>
>>> people select: #name >> #size >> #even
>>>
>>> (I use >> as example).
>>> Generally it is about functional programming. Would be nice to have this
>>> in image because it will simplify scripting a lot.
>>> I remember nice set of blog posts from Vassili Bykov about such kind of
>>> things http://blog.3plus4.org/2007/03/.
>>>
>>>
>> This code has a cost, however.
>>
>> First, it's rather slow (hidden #perform: in there).
>>
>> Second, I had a first hand experience that it is making it significantly
>> more complex to understand for newcomers (implying that it creates
>> additional, special semantics compared to basic smalltalk). I know that
>> there is no special semantic involved, but it looks as if to practitionners
>> of other programming languages and their complex semantics.
>>
>> I do like the SortFunctions idea (and its extension), but it's important
>> IMHO to not make it too cryptic.
>>
>
> That's why I said it is not related to SortFunction.
> Generally we rarely use symbol for #collect:/#select: in production. But
> it is supper handy for scripting/debugging/inspecting. I use it all the
> time.
>

Hum, among users of # symbol instead of blocks, they do leave it in
production. Or they have a different concept of "production" than I do.


> Also performance in that case can be covered by Sista.
>

Sure.


> Another problem: it complicates debugging because it is not easy to step
> into selector in that case. With block we just press "Through" button and
> we are done. But I am sure we can improve it too. Our debugger is in our
> hands.
>

Yes, this is a concern.


>
> Another advantage of symbol based functions: there is not potential memory
> leak here. In case of block we always have reference to outer context. So
> it is dangerous to use blocks in caches for example.
>

Clean blocks are easy to check for.

Thierry


>
>
>> Regards,
>>
>> Thierry
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171107/a5c56789/attachment-0002.html>


More information about the Pharo-dev mailing list