Re: [Boost-users] formal review of Switch library ends tomorrow (Wednesday, January 9th) - reviews needed

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-10 04:52:19

Joel de Guzman wrote:
> Tobias Schwinger wrote:
>> Joel de Guzman wrote:
>>> Tobias Schwinger wrote:
>>>> Stjepan Rajko wrote:
>>>>>     * What is your evaluation of the design?
>>>> I very much like the simplicity.
>>>>
>>>> I'm not sure it really suits the name 'switch_', as I'd expect something
>>>> syntactically different (something like Joel sketched out in his review,
>>>> and with some argument forwarding), however, I think it's an important
>>>> building block that should be kept as simple as possible.
>>> I can assure you that my suggestion is "as simple as possible, but
>>> not simpler" ;-) Simpler than that is simply not usable to me.
>>> I know. I've been there many times. I have real world use cases
>>> for this thing. Switch is not simple. Let's not pretend it is.
>> My point is that the utility we have here is in fact too different from 
>> phoenix::switch_ to compare the two (and that boost::switch_ is not the 
>> best name):
> 
> Maybe.

Yes, maybe ;-).

...

> Oughta do it. Did that clear things up?

Yep.

FP switch has its place - but it's not what we've got here. This one's 
about automation.

Granted, both could be combined - exposing some sort of "fused switch" 
(taking a sequence) and I'd be all for it if compile time was for free.

>> This utility is about generating the machine code of 'switch'. It does 
>> not necessarily have to mimic it's syntax!
> 
> Why not? Syntax matters! 

It sure does and elegance is formally defined as the least you can get 
away with ;-).

> And again, it's not just syntax. Why
> limit yourself to a not-really-a-switch-but-similar library when
> you can have a real-switch library with all the possibilities
> that switch can provide -- fallback, individual functions,
> defaults, etc.

Because a not-really-a-switch-but-similar utility suffices in many use 
cases and provides a more lightweight building block which really-switch 
can be easily implemented on top of.

The fact that we can't do it the other way around (at least not easily 
-- even given "fused switch") indicates that the current design is the 
better-suited one for automation purposes!

>> Also also note that the 'switch_' name is obviously confusing :-).
> 
> Because the API *is* confusing. 

I had a look at this utility back when Steven first posted it and had 
similar doubts. I tried to write Steven about it, but the email never 
got finished and while trying I realized I got misled by the name.

> Why invent another scheme
> when we can mimic a well-proven, time-tested mechanism,

It isn't about inventing -- it's about reducing switch to its essence!

Regards,
Tobias