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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project