[Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

csrabak at bol.com.br csrabak at bol.com.br
Tue Feb 15 20:38:40 CET 2011


Em 15/02/2011 17:03, Igor Stasenko < siguctua at gmail.com > escreveu:
On 15 February 2011 19:23, wrote:

> > Em 13/02/2011 21:21,  Stephen Taylor < stephen.taylor at bom.gov.au >
> > escreveu: 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 :)
> > Igor's attitude, which I'll take  as sample of a school of thought
> > is dangerously similar to the one which in name of keeping certain
> > aspects of  Smalltalk "pure" or near  to the origins  has made its
> > acceptance fall as the other  aspects of the technology (OO, WIMP,
> > etc.), made their way into other languages/platforms/technologies.
> >
>  I am not opposed to innovations or cross-breeding techs.  My purism
> lies on simple principle: KISS.   If something could be made simpler
> without losing key features then it should done.

Your KISS principle has to come at odds with another one, which was the reason why the construct was put in place: performance.  

This is called engineering, it is the art of trade off.

>
>
> >> You didn't answer the question though.
> > And then this:  to the first concrete example,  no complete answer
> > comes out  which we  could check if  the code construct  is indeed
> > only a  syntactic sugar, or deserves incorporation  in the toolset
> > of the language...
> >  I don't  see  a need  of  explaining how  to  interpret a  simple
> translation without using caseOf: statement.

You don't, because you already decided that what it is at stake doesn't 
matter for Pharo.

I'm just trying to recap here: the construct is not here to mud the purity of a beatiful OO language nor be incentive to bad code smells.  It has been put to solve a particular problem in a very specific part of the system.


>
> >>  > 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?
> > FWIW, this kind  of need, namely having to  take alternate actions
> > due different integer codes is pretty common when interfacing with
> > industrial boards, a lot of protocols use this as well and most of
> > them are already in use, some even have international standards.
>  And i suspect that all these standards are properly documented, and
> each signal/number having its description, so you can represent them
> by names, not by numbers.
>

I may lost something, but how will you convert the numbers in names to start with?


> > So the answer "redesign your world to fit our world-view" does not
> > cut in...
> >
>  I'm not asking  you to redesign C world to  fit smalltalk view. Use
> each  tool  what it  made  for.   What i  asking  is  to  not use  a
> microscope for hammering nails. Hammer is much better tool for that.
>

This statement is called in Informal Logic "the Fallacy of the False Analogy".

> > Also, another  argument I've seen  in this thread which  is pretty
> >commonplace w.r.t. performance must be extirpated in our discourse:
> >"the  performance x  to  y  slower than  is  very good  considering
> >{dynamic} languages (or similar statement)".
> > Performance counts!
>  Sure. At  some point if you  train long enough you  can hammer nail
> using  microscope much  faster  than using  hammer.  But that  still
> doesn't means that you doing it right :)

As I already pointed out, your base reasoning is false, this is consequentially /non sequitur/.





More information about the Pharo-project mailing list