Not really, but I'd be interested in understanding why it's overengineering for Ordering but not for Boolean…
On 9 November 2017 at 14:16, Denis Kudriashov <[email protected]> wrote: > Hi Damien. > > 2017-11-09 14:00 GMT+01:00 Damien Pollet <[email protected]>: > >> >> >> On 7 November 2017 at 14:48, Denis Kudriashov <[email protected]> >> wrote: >>> >>> 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. >>> >> >> If we're modifying core sorting methods, we might as well use proper >> objects instead of magic numbers… >> >> Ordering >> Lesser >> Equal >> Greater >> (Unordered?) >> > > I also thought about it. But it looks like overengineering to me. These > magic numbers are too well known to be magic. > Do you have real cases where this approach will improve the code? > > >> >> And while I'm on the topic of vocabulary, I'm not convinced by >> SortFunction… "to sort" means either to screen, to classify, or to arrange. >> There is a notion of going through all elements and swapping them around or >> putting in specific bins. Think QuickSort, MergeSort, etc >> >> The mathematical term for the thing that determines whether two elements >> a and b are such that a ≤ b is "Order relation". So IMHO Java's Comparator >> fits the purpose much better; OrderFunction or OrderRelation would be nice >> and just Order would have my preference: >> >> Order with: aPredicate >> (Order with: [:a :b | a < b]) value: 1 value 2. → the singleton instance >> of Lesser >> >> Order by: aMappingBlock >> people sorted: (Order by: #name) , (Order by: #age) >> >> Lesser >> #, innerOrder >> ^ self >> >> Equal >> #, innerOrder >> ^ innerOrder >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
