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

Schwab,Wilhelm K bschwab at anest.ufl.edu
Tue Feb 15 19:55:02 CET 2011

I am not completely certain who is on which side here anymore, other than #caseOf: is at the center of it.  I think I saw Eliot say that Cog uses it; if I got that right, it's a pretty compelling reason to keep it in the image.  Doing that, either for Cog's benefit, or even just for the convenience of a subset of users does not necessarily imply that Pharo itself needs to use the message.  That is about the limit of what I can offer in the form of guidance, and it is really more of a question: could Pharo be changed to ignore the message, and then keep it in the image for Cog and other users?  Maybe that is too idealistic, or just plain naive :)

Mapping integers from the outside world to objects and/or behavior is something that I do a lot.  I have to more or less agree with Sig; case statements as such generally point to room for a design to better exploit messaging.  There are indeed scenarios (especially if not exclusively in external interfacing) that call for mapping numbers to actions.  I have had great results with dictionaries for that purpose, but I am not trying to squeeze every last byte code per second out of a portable VM.  

There have been situations in which Smalltalkers have climbed the ivory tower and looked with contempt on things that make the world work.  I am not convinced that is happening here.

From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br [csrabak at bol.com.br]
Sent: Tuesday, February 15, 2011 1:23 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project]    could we agree to remove caseOf: and    caseOf:otherwise:

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