[Pharo-dev] change weird String compare: method (was about SortFunctions)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Nov 7 09:02:03 EST 2017


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

> 2017-11-07 14:45 GMT+01:00 Denis Kudriashov <dionisiydk at gmail.com>:
>
>> 2017-11-07 14:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.com>:
>>
>>>
>>>
>>> 2017-11-07 14:20 GMT+01:00 Denis Kudriashov <dionisiydk at gmail.com>:
>>>
>>>> I have new question. Why we really need threeWayCompareTo:?
>>>> DefaultSortFunction can implement it using standard comparison methods.
>>>>
>>>>
>>> But what would the DefaultSortFunction use?
>>> 2 among the 3 selectors < = > ?
>>> It's just that we might scan String twice when <=> would do it once, but
>>> apart that is OK
>>>
>>
>> Yes, you are right.
>> And we already have VM based String compare: with strange logic returning
>> 1, 2, 3. So we already can optimize current String>>threeWayCompareTo:.
>>
>
> Maybe good idea to open ticket and modify image level methods to return
> standard -1,0,1 values.
>
>

We should have done that for long.
But we want to avoid images to behave differentlly depending on VM version.

Possibility 1:
add a new primitive, marking the old as for backward compatibility, and
modify image side
with backward compatibility support (try new prim, if failure try old, if
failure revert to Smalltalk code)

Since this primitive is only for accelerating things and not strictly
necessary, we don't need backward compatibility so:

Possibility 2:
add a new primitive, and modify image side (try new prim if failure then
revert to Smalltalk code)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171107/24696b5b/attachment-0002.html>


More information about the Pharo-dev mailing list