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

Igor Stasenko siguctua at gmail.com
Mon Feb 14 10:13:25 CET 2011

On 14 February 2011 01:32, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
> 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.

Because it sounds rhetoric to me.
How to deal with randomly put integers coming from outer source?
If you're a software engineer, you should know it. :)

But i can explain my vision:
 - first try to avoid dealing with them. So if you can control the
protocol, use other ways of encoding actions/data.

 - organize these numbers (using dictionary or whatever), so they
won't look like a random noise
for people who first looking at your code. Put them into single place
with documentation etc. And convert them to their symbolic
representation as soon as possible.

 - never use bare numbers  as a labels which influencing a control
flow (like in switch statement,  branches etc). Instead, use their
symbolic names.
This will prevent many many many errors, typos and mistakes and make
your code more documented.

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

Best regards,
Igor Stasenko AKA sig.

More information about the Pharo-project mailing list