[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:27:58 CET 2011

This solution has the disadvantages of caseOf: solution, namely a non OO approach requiring maintenance in several places in the code, and the disadvantages of having less performance on the speed metric.

I think it is capricious to stick to it, except if the Smalltalk flavour you're using does not offer the caseOf: construct.
my 0.0199999...

Cesar Rabak

Em 13/02/2011 22:32, Schwab,Wilhelm K < bschwab at anest.ufl.edu > escreveu:
That's where I typically use a dictionary.  Map the numbers to what is often a factory (a factory that reads from a stream being a common scenario) or sometimes closures.  Create the map once on class initialization or once per "session" (or at least try not to build the map "every time"), and the result is reasonably efficient.  It is really no different from what Smalltalk user interface frameworks do to dispatch messages to objects.  Obviously, if the numbers are contiguous, one could use an array, but I find a dictionary convenient because there is no need to mess with offsets.

From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Stephen Taylor [stephen.taylor at bom.gov.au]
Sent: Sunday, February 13, 2011 6:21 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] could we agree to remove caseOf:   and     caseOf:otherwise:

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

You didn't answer the question though.

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


More information about the Pharo-project mailing list