Hi!

Ned Konz <ned at bike-nomad.com> wrote:
[SNIP]
> Why not just:
> 
> reversed
> 	| newSortBlock newCollection |
> 	newCollection _ self class new: self size.
> 	newSortBlock _ sortBlock ifNil: [ [ :a :b | b < a  ] ]
> 		ifNotNil: [ [ :a :b | sortBlock value: b value: a  ] ].
> 	newCollection sortBlock: newSortBlock fixTemps.
> 	newCollection addAll: self.
> 	^newCollection.
> 
> I don't know why you have to keep track of whether it's been reversed before, 
> unless you're going to re-reverse the output of reversed.

Well, yes, that was the intent. It would feel kludgy if "a reversed
reversed" did not give back the same result as from the beginning.
 
> I tried to subclass BlockContext to make a ReversedBlockContext (that would 
> define, for instance,

Ah yes, how come I did not think of that? Polymorphism, polymorphism,
now write that 100 times...

> ReversedBlockContext>>value: a value: b
>         ^super value: b value: a
> 
> But it blew up the VM when I actually tried to evaluate one.

Oops.
 
> I figured that you could have a method
> 
> BlockContext>>reversed
>      ^self as: ReversedBlockContext
> 
> and use that in SortedCollection>>reversed (which would allow un-reversal).

Yes, very slick. I like this approach even though it disturbs me to
change BlockContext... I wonder what Dan would say? :-) Dan?

BTW - Mark van Gulik also proposed a similar solution which could be
even more generalized into "negated blocks" where any number of
arguments could be reversed in order...

PS. I have submitted a small .cs to Doug just doing
SortedCollection>>reversed as "^self asOrderedCollection reversed" which
at least makes it less "a bug". Ds
 
regards, Göran