<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt">I mostly agree with you on all points Bill..&nbsp; It's just that usually, "ugliness" in Smalltalk, is a symptom of bad design or at least that something could be refactored a little bit more...&nbsp; In all the years and all the Smalltalk implementations, why did no one ever implemented Number arithmetic operations using case statements (or case style) and used double dispatch instead ??&nbsp; I guess there are many other ways this could have been implemented more effectively (performance-wise) but simplicity &amp; clarity seem to have won.&nbsp; Simplicity &amp; clarity have their merits.&nbsp; It's no wonder, a few years ago, there was a Smalltalk implementation that allowed "assembly code" inside Smalltalk code but this feature never got popular even though "it could have been extremely fast".&nbsp; What
 a real mess.&nbsp; Probably really efficient &amp; fast but was a mess from a readability &amp; maintenance standpoint...<br><br>I'm just really skeptical about always presenting speed as the main argument when it comes to Smalltalk &amp; the way to code and implement things.&nbsp; It's like having a Cessna and trying to make it fly like the space shuttle.&nbsp; It wasn't designed for that.&nbsp; Yes we could add boosters, yes we could extend the wings, yes we could change the engine, yes we could patch this, yes we could do that, etc.&nbsp; If I want to go to the moon, I'll use the Space Shuttle but in the meantime, I must not forget I'm piloting and using a Cessna.<br><br>This #caseOf:otherwise: painfully reminds me of a coding horror I saw years ago...&nbsp; The programmer told us he was never sure of the receiver (a few possible classes only) and had to rely on a "very useful and flexible" method called #ifTrue:ifFalse:ifNil:ifEmpty:otherwise:&nbsp;
 .Obviously, you can only imagine the rest of the "logic" involved where this method was called...&nbsp; Double dispatching would have been so simpler and more elegant.&nbsp; It felt like doing BASIC a class browser !<br><br>I'm not against change when needed.&nbsp; I'm not against suggestions.&nbsp; I'm not against speed improvements. But I'm not for speed at all costs, especially code readability.&nbsp; If we want speed, it's in the VM we have to implement it.&nbsp; Cincom rarely relied on ugly Smalltalk code implementations to make VW faster.&nbsp; They pushed the VM.&nbsp; Not the Collection hierrachy, not the Number hierarchy, not the Stream, etc.<br><br>Besides, performance arguments is a slippery slope.&nbsp; What about memory consumption?&nbsp; Which road should we take ?&nbsp; It's fast but it instantiates 10 million objects or it's small and used 3Ks of memory but runs 5 seconds slower?&nbsp; There's always another side to what "efficiency"
 means to everyone.<br><br>My 2 cents!<br><br>:)<br><br><br><div>&nbsp;</div>-----------------<br>Benoit St-Jean<br>Yahoo! Messenger: bstjean<br>A standpoint is an intellectual horizon of radius zero.<br>(Albert Einstein)<div><br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><br><div style="font-family: verdana,helvetica,sans-serif; font-size: 8pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> "Schwab,Wilhelm K" &lt;bschwab@anest.ufl.edu&gt;<br><b><span style="font-weight: bold;">To:</span></b> "Pharo-project@lists.gforge.inria.fr" &lt;Pharo-project@lists.gforge.inria.fr&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Sun, February 13, 2011 12:13:41 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:<br></font><br>Read the Federalist Papers and Bastiat's "The Law," and then we
 can talk about democracy, one illustration of which is three wolves and a sheep voting on the dinner menu.&nbsp; In its raw form, yes, I argue against democracy, aka mob rule.<br><br>However, we are not talking about taking someone's life, liberty or property here: this is software, and one can always retain #caseOf: in any image.&nbsp; However, a vote seems reasonable.&nbsp; I would be just as willing to accept the ruling of the benign dictators.<br><br>A switch often suggests inadequate reification (aka direct polymorphism or double dispatch might be in order), but I sometimes resort to a dictionary as a quick way to map numbers or strings to actions.&nbsp; Since landing in Pharo, I have been using the modified stream protocol I developed in response to default actions, which I consider to be a disaster in the making.&nbsp; Others are less worried about it.&nbsp; It is fairly easy to have some code that one loads into an image.&nbsp; I do it for
 streams, others can do it for case statements.<br><br>The above said, one thing I don't like is "you can't do that because I think its' ugly."&nbsp; Perhaps a compromise for Stef to consider is to clean the uses of the method so it is not used in the image (effectively removing it), but leave it in place for those who want to use it their own code??<br><br>Bill<br><br><br>________________________________________<br>From: <a ymailto="mailto:pharo-project-bounces@lists.gforge.inria.fr" href="mailto:pharo-project-bounces@lists.gforge.inria.fr">pharo-project-bounces@lists.gforge.inria.fr</a> [<a ymailto="mailto:pharo-project-bounces@lists.gforge.inria.fr" href="mailto:pharo-project-bounces@lists.gforge.inria.fr">pharo-project-bounces@lists.gforge.inria.fr</a>] On Behalf Of Benoit St-Jean [<a ymailto="mailto:bstjean@yahoo.com" href="mailto:bstjean@yahoo.com">bstjean@yahoo.com</a>]<br>Sent: Sunday, February 13, 2011 9:43 AM<br>To: <a
 ymailto="mailto:Pharo-project@lists.gforge.inria.fr" href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>Subject: Re: [Pharo-project] could we agree to remove caseOf: and&nbsp; &nbsp; &nbsp;  caseOf:otherwise:<br><br>Let's get to the point here...&nbsp; Most people will tell you it's an awful "beast" that doesn't belong to the OO and Smalltalk world.&nbsp; If I *love* case statements and I absolutely need them, I can code in C.&nbsp; If I *love* case statements and I absolutely need them, nothing prevents me from adding them to the image as my own-superoptimized extension.&nbsp; 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...&nbsp; 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 ?).<br><br>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.<br><br>On a less serious note, let's all remember what Spock said:<br><br>"Were I to invoke logic, however, logic clearly dictates that the needs of the many outweigh the needs of the few"<br><br>Let's remove this thing!<br><br>+1<br><br>P.S.&nbsp; Performance-wise, if you always need "optimized" code, you can always rely on primitives &amp; plugins...&nbsp; Let's not go performance-frenzy here!&nbsp; We don't want to end up in an environment where all the code is unreadable...&nbsp; Clarity &amp; simplicity are good, not evil in Smalltalk!<br><br>-----------------<br>Benoit St-Jean<br>Yahoo! Messenger: bstjean<br>A standpoint is an intellectual horizon of radius zero.<br>(Albert
 Einstein)<br><br><br>________________________________<br>From: Levente Uzonyi &lt;<a ymailto="mailto:leves@elte.hu" href="mailto:leves@elte.hu">leves@elte.hu</a>&gt;<br>To: <a ymailto="mailto:Pharo-project@lists.gforge.inria.fr" href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>Sent: Sun, February 13, 2011 8:50:53 AM<br>Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:<br><br>On Sun, 13 Feb 2011, Sven Van Caekenberghe wrote:<br><br>&gt;<br>&gt; On 12 Feb 2011, at 18:41, Levente Uzonyi wrote:<br>&gt;<br>&gt;&gt; ~27x slowdown in this case.<br>&gt;<br>&gt; I personally never heard of #caseOf:otherwise !<br>&gt;<br>&gt; It feels like a hack that is not often needed.<br><br>You don't need it often, but it's sometimes useful.<br><br>&gt;<br>&gt; 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.<br><br>The blocks of #caseOf: are not just boilerplate code, you can evaluate<br>any expression there. It's cumbersome to do that with table based<br>dispatch.<br><br>&gt;<br>&gt; 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:<br><br>It's not a problem, it's intentional. See the mail that I replied to.<br><br><br>Levente<br><br>&gt;<br>&gt; (timings on my machine)<br>&gt;<br>&gt; [ 1 to: 10 do: [ :each |<br>&gt;&nbsp; &nbsp;  each<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  caseOf: {<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  [ 1 ] -&gt; [ $a ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  [ 2 ] -&gt; [ $b ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  [ 3 ] -&gt; [ $c ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  [ 4 ] -&gt; [ $d
 ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  [ 5 ] -&gt; [ $e ] }<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  otherwise: [ $x ] ] ] bench.<br>&gt; '8,920,000 per second.'<br>&gt;<br>&gt; [ 1 to: 10 do: [ :each |<br>&gt;&nbsp; &nbsp;  ({<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  [ 1 ] -&gt; [ $a ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  [ 2 ] -&gt; [ $b ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  [ 3 ] -&gt; [ $c ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  [ 4 ] -&gt; [ $d ].<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp;  [ 5 ] -&gt; [ $e ] }<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  detect: [ :ea | ea key value = each ]<br>&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  ifNone: [ [ $x ] ]) value ] ] bench.<br>&gt; '70,600 per second.'<br>&gt;<br>&gt; | actions |<br>&gt; actions := { [ $a ]. [ $b ]. [ $c ]. [ $d ]. [ $e ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. }.<br>&gt; [ 1 to: 10 do: [ :each |<br>&gt;&nbsp; &nbsp;  (actions at: each) value ] ] bench.<br>&gt; '3,230,000 per
 second.'<br>&gt;<br>&gt; | letters |<br>&gt; letters := 'abcdexxxxx'.<br>&gt; [ 1 to: 10 do: [ :each |<br>&gt;&nbsp; &nbsp;  letters at: each ] ] bench.<br>&gt; '8,930,000 per second.'<br>&gt;<br>&gt; If other Smalltalks can live without it, so can we.<br>&gt;<br>&gt; Sven<br>&gt;<br>&gt;<br>&gt;<br><br><br><br></div></div>
</div><br></body></html>