You wrote "In general reversed/converse has no meaning for block."
That's entirely an artefact of representing blocks of different
arities by the same class. In my own Smalltalk, NiladicBlock,
MonadicBlock, DyadicBlock, ... are different classes. To put it
another way, your statement has exactly
2018-04-25 14:26 GMT+02:00 Richard O'Keefe :
> (aSortFunction value: x value: y) returns a Boolean;
> (aSortFunction value: x value: x) returns true.
> So you can already set up a SortedCollection using
> a SortFunction. So yes, that would work.
>
Yes. It was original goal to introduce them.
I c
(aSortFunction value: x value: y) returns a Boolean;
(aSortFunction value: x value: x) returns true.
So you can already set up a SortedCollection using
a SortFunction. So yes, that would work.
But there is no reason why #reversed (or my preference,
#converse) could not work on sortBlocks.
On 25
As I pointed out yesterday, #sort and its immediate relatives
are not alone. Look at #isSortedBy: . When do you want
(#(1 1 1) asSortedCollection: b) isSortedBy: b
to answer false?
There are several reasons for sorting. One is so that you
can use binary search. It's rather disconcerting that t
Hi Richard.
I agree with your proposal.
But it force me to think that we should completely move to SortFunction's.
In that case SortCollection will have sortFunction variable instead of
sortBlock. And for your scenario reverse operation will be simple
expression: "sortFunction := sortFunction reve
Why does the sortBlock has to answer true for the same (identical) object? I
have not been able to find where it is specified. And in different locations
I see #> being used as a comparator for the sortBlock. So why is it bad (as
you wrote)? (It seems you describe that SortedCollection should creat
Let me offer a simple example.
#(a a) isSortedBy: [:x :y | (x <= y) not]
is false, while
#(a a) isSortedBy: [:x :y | y <= x]
is true.
On 24 April 2018 at 02:43, Erik Stel wrote:
> Richard,
>
> Can you explain me what you mean by "sortBlock is supposed to act like
> #<="?
> Isn't it up to the dev
"sortBlock is supposed to act like #<=" means
"for every triple of elements x y z that might be
in the collection,
b(x,x) is true
b(x,y) is Boolean
b(x,y) | b(y,x)
b(x,y) & b(y,z) implies b(x,z)."
The first condition distinguishes it from #< .
In particular, if you want to sort a sequence
Richard,
Can you explain me what you mean by "sortBlock is supposed to act like #<="?
Isn't it up to the developer to decide what the logic should be? I simply
used #<= because #> might not have been implemented for all relevant
classes, but would otherwise have chosen #> as a means to get the 're
I already deleted my post (within 1 minute after posting 8-) seeing that I
jumped the wagon too early. Sorry for that. Your message and proposed
solution is fine.
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
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
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)
sortBlo
12 matches
Mail list logo
