https://forum.world.st/could-we-agree-to-remove-caseOf-and-caseOf-otherwise-tp3302475p3303347.html
> On Sun, 13 Feb 2011, Igor Stasenko wrote:
>
>> On 13 February 2011 00:59, Levente Uzonyi <
[hidden email]> 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 it.
>
>>
>> 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
>
Please read the Ian's paper about switch statement vs message sends..
You will discover something surprising for you.