SortedCollection reversed...
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Mon Oct 22 13:18:18 UTC 2001
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
More information about the Squeak-dev
mailing list
|