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

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

...

2017-11-07 14:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:

...

2017-11-07 14:20 GMT+01:00 Denis Kudriashov <dionisiydk@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)