I know perfectly well what the problem is. I explained it in my message: the inherited #reversed method doesn't know the sortBlock exists. (So whether it is nil or not is not relevant.)
I also know several ways to fix it, and provided tested source code for one of them in my message. Using (a <= b) not would be a bad idea as a sortBlock is supposed to act like #<=, not like #<. (That has always puzzled me: why take #< as the fundamental operation in Magnitude but #<= as the fundamental operation in sorting? But that is historic and standard practice.) On 23 April 2018 at 19:10, Erik Stel <erik.s...@gmail.com> wrote: > Richard, > > The 'problem' is that the result of the (original) #reverse is a > SortedCollection without a sortBlock. Meaning it defaults to comparing > values using #<=. When a new element is added to the reversed collection it > simply assumes all elements are already sorted and uses the (default) > sortBlock to add a new element. > > I think the solution should be to have #reverse add an explicit sortBlock > which consists of reversing the original sortBlock or defaulting to [ a: b: > | (a <= b) not ]. (Keep #<= as some classes might depend on only > implementing this) > > Cheers, > Erik > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >
