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

csrabak at bol.com.br csrabak at bol.com.br
Tue Feb 15 19:23:52 CET 2011

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.

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

So the answer "redesign your world to fit our world-view" does not cut in...

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

More information about the Pharo-project mailing list