could we agree to remove caseOf: and caseOf:otherwise:

> Le 13/02/2011 04:05, Ricardo Moran a écrit :
>> Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere.
> no, it allows people to make their own opinion.
> interesting thread.
>
> Now I can say that I would be more for getting rid of case of.
>
> thanks
> Alain
>
>
>

> Cheers,
> Doru
>
>
> On 13 Feb 2011, at 08:57, Stéphane Ducasse wrote:
>
>> Hi ricardo, igor and levente
>>
>> I really want to remove caseOf: since years.
>> Why:
>>       - conceptually wrong (even if this may be nice to have for $A and numbers)
>>       - to me it looks like coming from another age
>>       - never needs to use it: of course other people may of course
>>       - Three less methods in Object
>>       - only available in Squeak/Pharo
>>       - but more more more important:
>>               makes the compiler, decompiler, inliner....., more complex.
>>       I want opal to get out because we need a better infrastructure: simpler, better compiler.
>>       - Ideally I would prefer that we can extend the compiler with it and that people needed it just ship a plugin with
>>       their code.
>>
>> Marcus is opal dealing with caseOf:?
>>
>> I did not want to have a war. I thought that it was pretty obvious that we do not really need that.
>>
>> Stef
>>
>>> Ok, guys... I'm sorry to interrupt this polite discussion, but this is taking nowhere. Having such strong arguments (for or against) is not helpful for anybody.
>>> We all know using #caseOf:otherwise: it's not exactly good style, but sometimes you need to compromise between design and efficiency, and having simple and efficient constructs such as #caseOf: is very good IMHO.
>>> You are free to avoid them if your projects don't need it, and if you happen to need extra performance you can always build your own JIT, right? :)
>>> But please don't ban people who are willing to sacrifice a little readability for performance reasons. Thanks.
>>>
>>> Best regards.
>>> Richo
>>
>>
>
> --
> www.tudorgirba.com
>
> "Value is always contextual."
>
>
>
>
>

>
> (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
>
>
>

>
> (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
>
>
>

> Of course discussion is good. But turning your position into a religion and
> blaming other parties ignorance is bad. That's what the discussion seemed to
> be heading (at least to me) and I just tried to avoid that.
> Maybe I'm just too new in this community (and smalltalk in general, for that
> matter) and this is how you solve your discussions, but I just don't like
> arguments such: "I don't like it and everyone using it should die" :)
> Now that more voices have joined the thread I think we are actually getting
> somewhere :)
> Cheers
> Richo
>
> On Sun, Feb 13, 2011 at 7:58 AM, Alain Plantec <[hidden email]>
> wrote:
>>
>> Le 13/02/2011 04:05, Ricardo Moran a écrit :
>>>
>>> Ok, guys... I'm sorry to interrupt this polite discussion, but this is
>>> taking nowhere.
>>
>> no, it allows people to make their own opinion.
>> interesting thread.
>>
>> Now I can say that I would be more for getting rid of case of.
>>
>> thanks
>> Alain
>>
>>
>>
>
>

> I mostly agree with you on all points Bill..  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...  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 ??  I guess there are many other ways this
> could have been implemented more effectively (performance-wise) but
> simplicity & clarity seem to have won.  Simplicity & clarity have their
> merits.  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".  What a real mess.  Probably really efficient & fast but was a
> mess from a readability & maintenance standpoint...
>
> I'm just really skeptical about always presenting speed as the main
> argument when it comes to Smalltalk & the way to code and implement
> things.  It's like having a Cessna and trying to make it fly like the
> space shuttle.  It wasn't designed for that.  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.  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.
>
> This #caseOf:otherwise: painfully reminds me of a coding horror I saw
> years ago...  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:
> .Obviously, you can only imagine the rest of the "logic" involved where
> this method was called...  Double dispatching would have been so simpler
> and more elegant.  It felt like doing BASIC a class browser !
>
> I'm not against change when needed.  I'm not against suggestions.  I'm
> not against speed improvements. But I'm not for speed at all costs,
> especially code readability.  If we want speed, it's in the VM we have
> to implement it.  Cincom rarely relied on ugly Smalltalk code
> implementations to make VW faster.  They pushed the VM.  Not the
> Collection hierrachy, not the Number hierarchy, not the Stream, etc.
>
> Besides, performance arguments is a slippery slope.  What about memory
> consumption?  Which road should we take ?  It's fast but it instantiates
> 10 million objects or it's small and used 3Ks of memory but runs 5
> seconds slower?  There's always another side to what "efficiency" means
> to everyone.
>
> My 2 cents!
>
> :)
>
>
>  
> -----------------
> Benoit St-Jean
> Yahoo! Messenger: bstjean
> A standpoint is an intellectual horizon of radius zero.
> (Albert Einstein)
>
>
> ------------------------------------------------------------------------
> *From:* "Schwab,Wilhelm K" <[hidden email]>
> *To:* "[hidden email]"
> <[hidden email]>
> *Sent:* Sun, February 13, 2011 12:13:41 PM
> *Subject:* Re: [Pharo-project] could we agree to remove caseOf: and
> caseOf:otherwise:
>
> 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.  In its raw form, yes, I argue against
> democracy, aka mob rule.
>
> 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.  However, a vote seems reasonable.  I would be just as
> willing to accept the ruling of the benign dictators.
>
> 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.  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.  Others are less worried about it.  It is fairly
> easy to have some code that one loads into an image.  I do it for
> streams, others can do it for case statements.
>
> The above said, one thing I don't like is "you can't do that because I
> think its' ugly."  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??
>
> Bill
>
>
> ________________________________________
> From: [hidden email]
> <mailto:[hidden email]>
> [[hidden email]
> <mailto:[hidden email]>] On Behalf Of
> Benoit St-Jean [[hidden email] <mailto:[hidden email]>]
> Sent: Sunday, February 13, 2011 9:43 AM
> To: [hidden email]
> <mailto:[hidden email]>
> Subject: Re: [Pharo-project] could we agree to remove caseOf: and    
> caseOf:otherwise:
>
> 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 <[hidden email] <mailto:[hidden email]>>
> To: [hidden email]
> <mailto:[hidden email]>
> 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
>>
>>
>>
>
>
>
>

> Now that more voices have joined the thread I think we are actually getting
> somewhere :)
> Cheers
> Richo
>
> On Sun, Feb 13, 2011 at 7:58 AM, Alain Plantec <[hidden email]>
> wrote:
>>
>> Le 13/02/2011 04:05, Ricardo Moran a écrit :
>>>
>>> Ok, guys... I'm sorry to interrupt this polite discussion, but this is
>>> taking nowhere.
>>
>> no, it allows people to make their own opinion.
>> interesting thread.
>>
>> Now I can say that I would be more for getting rid of case of.
>>
>> thanks
>> Alain
>>
>>
>>
>
>

>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Stephen Taylor [[hidden email]]
> Sent: Sunday, February 13, 2011 6:21 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] could we agree to remove caseOf:   and     caseOf:otherwise:
>
> Igor Stasenko wrote:
>
>>> You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a
>>> variable's value is equal to any of these...
>
>> Don't try to convince me that there are sort of problems which can be
>> solved only by using case statement :)
>
> You didn't answer the question though.
>

>> First, get rid of these integers in your code.
>
> That's the killer - yes, we can usually design around cases where we'd
> use case constructs (though I'm not convinced they're the spawn of the
> devil) but what about cases where we're interfacing with external data
> sources and we don't get to redesign the whole system to suit our needs?
>
>
>
>               Steve

>
> I agree with both Igor and Levente.
>
> Uses of caseOf: is often times solvable in more "elegant" ways.
>
> Though, I think in f.ex. HandMorph>>#processEvents  and
> UTF8TextConverter>>nextFromStream:, it would actually *improve* readability
> to use it.
>
> Got any good refactoring to symbolics for those two, Igor? ;)
>

> Cheers,
> Henry
>
> -1 for removal/deprecation from me (from the system, not necessarily as
> special cases for the compiler)
> --
> View this message in context: http://forum.world.st/could-we-agree-to-remove-caseOf-and-caseOf-otherwise-tp3302475p3305140.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>

>
>
> On Fri, Feb 11, 2011 at 1:43 PM, stephane ducasse <[hidden email]>
> wrote:
>>
>> Hi guys
>>
>> let us do another pass at cleaning and realigning the system.
>> Could we agree to deprecate caseOf: and caseOf:otherwise:?
>> it will simply the compiler, decompiler and also we do not need that at
>> all.
>>
>> | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z
>>
>> =>
>> "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}.
>> z detect: [:each | each key value = #b] "
>>
>> there is one user which I fixing right now.
>
> please don't.  It is used in many places in Cog and would be extremely
> uncomfortable to live without.
>