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

Levente Uzonyi leves at elte.hu
Sun Feb 13 02:26:42 CET 2011

On Sun, 13 Feb 2011, Igor Stasenko wrote:

> On 13 February 2011 00:59, Levente Uzonyi <leves at elte.hu> wrote:
>> On Sun, 13 Feb 2011, Igor Stasenko wrote:
>>> Don't try to convince me that there are sort of problems which can be
>>> solved only by using case statement :)
>> We all know that it can be solved, but the solution won't be nicer at all,
>> instead it will be a lot slower.
>>> First, get rid of these integers in your code. Use symbolic names.
>>> And then for dispatching using parameter, there is a #peform: primitive.
>> The integers are from a binary stream, so I can't do much about it.
> Oh yeah? Too bad for you then.

And everyone trying to implement a binary protocol efficiently.

>>> So, then switch statement will be turned into:
>>> self peform: (self decode: someInteger)
>>> and this is how it should look like.
>>> And again, if you can avoid using integers at all, use symbols , so
>>> you don't have to decode/translate them.
>>> Just do #perform.
>>> I thought that this is obvious for you.
>> What you wrote here is obvious, but not an answer to my question. What
>> should #decode: do? Use #detect:? Or a dictionary? Maybe a binary search on
>> an array? Or should it be a bunch of #ifTrue:ifFalse: conditionals? (I guess
>> the separate class per integer idea is abandoned, but who knows.)
> I don't care. You should encapsulate them into something , which has a meaning.
> Use bare numbers without any docs/comments/explanations to C.
>> Also note that #perform:with: is ~11x slower on Cog than sending a message.
>> And a send is a lot slower (~5.5x IIRC) than a direct assignment. That's
>> ~55x combined slowdown not counting the integer->selector matching.
> Slower comparing to someone who will read your code and try to
> understand what it does.
> THAT WILL BE SLOWER and that is most precious resource we have,  not
> the CPU time.

Is #caseOf: unreadable? No it's not. You just don't like it for some 
unknown reason. And you're not willing to tell what's your problem with 

> Please read the
> http://www.c2.com/cgi/wiki?PrematureOptimization
> :)

I know what's premature optimization. What I do differently than other 
people (including you) is:
- if I can choose from different solutions for some problem, then I 
usually pick the one with the best expected performance if it has neglible 
other extra cost (complexity, readability, size, etc) compared to other 
solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:,
foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil 
ifFalse: [ ... ]), etc.
- I optimize library code which is expected to be heavily used
- I like to optimize code


>> Levente
> -- 
> Best regards,
> Igor Stasenko AKA sig.

More information about the Pharo-project mailing list