On Mon, 12 Apr 2010, Stéphane Ducasse wrote:
Hi levente
may be I did a mistake when I integrated some of your changes. I did not look
at Squeak before posting (because I'm dead).
Now in latest 1.1 several tests for sorted failed because nil is valued while
it should not.
I read the code and I do not really like the aBlockOrNil.
aBlockOrNil is a bit misleading, because it can be anything that
understands #value:value: or it can be nil. This means that the
following binary selectors can be used (if you integrated my changes)
instead of blocks: #<= #>= #< #> (or whatever you define :)).
Using nil is not my idea, I took it from SortedCollection.
I would prefer to have block all the time.
I was wondering if your original idea was to use nil and if this is the case
why you thought it was
better than just passing a block.
nil is only used for better performance. Since most of the time you
only want to sort by <=.
Here is a simple benchmark which do the same thing, but uses 3
different "sortBlocks":
| array |
array := (1 to: 100000) asArray shuffle.
[ array sorted: nil ] bench "===> 4.782781984854524 per second.".
[ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.".
[ array sorted: #<= ] bench "===> 2.740262282247015 per second."
Levente
sorted
"Return a new sequenceable collection which contains the same elements
as self but its
elements are sorted in ascending order using the #'<=' operator."
^self sorted: [:a :b| a <= b ]
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
