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

Igor Stasenko siguctua at gmail.com
Tue Feb 15 20:03:19 CET 2011


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


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

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

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

> 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 <baseline implementation> 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 :)

>One of the reasons we're working in Pharo is to bring its performance on par with competitive technologies.  We're doing things to take out 'cruft', some to make the abstractions more elegant, but some are pragmatic which require depart of breaking 'pure' Smalltalk OO way of thinking.
>
> --
> Cesar Rabak
>
>
>>
>>
>>  Steve
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list