Em 15/02/2011 17:03, Igor Stasenko < siguctua@gmail.com > escreveu: On 15 February 2011 19:23, wrote:
Em 13/02/2011 21:21, Stephen Taylor < stephen.taylor@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/.