Let's get to the point here... Most people will tell you it's an awful "beast" that doesn't belong to the OO and Smalltalk world. If I *love* case statements and I absolutely need them, I can code in C. If I *love* case statements and I absolutely need them, nothing prevents me from adding them to the image as my own-superoptimized extension. You'll always find something, someone, somewhere who could argue about the need for such a thing but in reality, I guess this method has always bugged most Smalltalkers... It's ugly, not OO, not good style and good practice, not essential and not needed by 99% of the people here (and if it's sooooooooooo needed, how do you explain that all other Smalltalk vendors haven't implement it as part of their core libraries ?).
So let's vote
(you won't argue against democracy, won't you?!) for the removal of #caseOf:otherwise: and let's move forward onto more important business.
On a less serious note, let's all remember what Spock said:
"Were I to invoke logic, however, logic clearly dictates that the needs of the many outweigh the needs of the few"
Let's remove this thing!
+1
P.S. Performance-wise, if you always need "optimized" code, you can always rely on primitives & plugins... Let's not go performance-frenzy here! We don't want to end up in an environment where all the code is unreadable... Clarity & simplicity are good, not evil in Smalltalk!
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)
From: Levente Uzonyi <leves@elte.hu>
To: Pharo-project@lists.gforge.inria.fr
Sent: Sun, February 13, 2011 8:50:53 AM
Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:
On Sun, 13 Feb 2011, Sven Van Caekenberghe wrote:
>
> On 12 Feb 2011, at 18:41, Levente Uzonyi wrote:
>
>> ~27x slowdown in this case.
>
> I personally never heard of #caseOf:otherwise !
>
> It feels like a hack that is not often needed.
You don't need it often, but it's sometimes useful.
>
> If after writing correct code you need to optimize integer/byte handling, there are many
solutions, check any book on algorithms, most of them are using table dispatch.
The blocks of #caseOf: are not just boilerplate code, you can evaluate
any expression there. It's cumbersome to do that with table based
dispatch.
>
> Another problem in your benchmark is that you keep the creation of the dynamic array inside the code to measure, while in the compiler primitive case it is of course compiled away, that alone makes a huge difference:
It's not a problem, it's intentional. See the mail that I replied to.
Levente
>
> (timings on my machine)
>
> [ 1 to: 10 do: [ :each |
> each
> caseOf: {
> [ 1 ] -> [ $a ].
> [ 2 ] -> [ $b ].
>
[ 3 ] -> [ $c ].
> [ 4 ] -> [ $d ].
> [ 5 ] -> [ $e ] }
> otherwise: [ $x ] ] ] bench.
> '8,920,000 per second.'
>
> [ 1 to: 10 do: [ :each |
> ({
> [ 1 ] -> [ $a ].
> [ 2 ] -> [ $b ].
> [ 3 ] -> [ $c ].
> [ 4 ] -> [ $d ].
> [ 5 ] -> [ $e ] }
> detect: [ :ea | ea key value = each ]
> ifNone: [ [ $x ] ]) value ] ] bench.
> '70,600 per
second.'
>
> | actions |
> actions := { [ $a ]. [ $b ]. [ $c ]. [ $d ]. [ $e ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. }.
> [ 1 to: 10 do: [ :each |
> (actions at: each) value ] ] bench.
> '3,230,000 per second.'
>
> | letters |
> letters := 'abcdexxxxx'.
> [ 1 to: 10 do: [ :each |
> letters at: each ] ] bench.
> '8,930,000 per second.'
>
> If other Smalltalks can live without it, so can we.
>
> Sven
>
>
>