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

Igor Stasenko siguctua at gmail.com
Tue Feb 15 21:02:04 CET 2011


On 15 February 2011 20:38,  <csrabak at bol.com.br> wrote:
> 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.
>

So we will never agree here. We are different and having different view on it.


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

nope.
I suspecting that it is there to mimic C switch statement.. because
some people, when discovering something new, often trying to bring
everything they knew/used before. Even if it doesn't fit.. But they
are loving they old toys too much for just leaving them behind.

Or they faulty thinking that some cool technique that served well for
them in one case, will serve as well everywhere , not depending on
environment. Such people are not trying to adapt themselves to new
environment, instead they trying to adapt environment for themselves.

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

name := numbers at: number.

where numbers is dictionary/table/whatever which contains translation.

Even C code using defines to represent numbers by names.

So, what you prefer to see in code. This:

switch (response)
 case 1:
  ..
 case 2:
  ..
 case 3:
  ..


or this:

#define Yes 1
#define No 2
#define NotSure 3

switch (response)
 case Yes:
  ..
 case No:
  ..
 case NotSure:
 ...


and what code to your thinking having better chance to evolve and/or
live longer than its original author?

>
>> > 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".
>

You may call it however you like.
Just don't convince me that it is a good idea to come to lab and use
microscope for hammering nails. Because its shape somewhat reminds the
hammer you using in garage.

>> > 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/.
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list