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

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-01-10 07:32:00

Tobias Schwinger wrote:

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

Huh? The fact that you have a higher order function makes it
essentially FP. Even the humblest for_each is FP.

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

* I'd be for the "simple" solution if the excess scaffolding
   you need to add to make it to the truer-switch is compile time
   free. Transforming the dumb switch_ to a smarter alternative
   would require Fusion.

* The change in interface to what I am suggesting does not
   have to be heavy in terms of additional code. It's just
   the syntax, basically. It can be done without Fusion.
   I know. I did it before. The smarts is almost already in
   the PP code.

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

That's also a thing a point of disagreement. My solution does not
have to be heavyweight. Implementing it on top of the dumb
solution, OTOH, will definitely be heavyweight, requiring Fusion.

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

I don't know what you mean by "other way around".

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

Again, why reduce the essence! To make it lightweight? Then,
I argue that you are wrong. My proposed interface does not
have to be heavyweight. It can be lightweight if done correctly
without intervening libraries like Fusion.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net