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 08:59:46

Tobias Schwinger wrote:
> Joel de Guzman wrote:
>> 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.
> 
> Yes, but that doesn't justify its existence -- the fact that you can 
> easily automate it without using the PP lib does!

I'm confused with that sentence. Doesn't make sense to me.
Steven's original interface is already FP out of the box.

> Both the built-in switch statement and the interfaces you proposed 
> restrict client code to a single number of cases which is known at 
> preprocessing time. Steven's approach OTOH allows the number of cases to 
> vary at compile time.
> 
> Further, requiring a function object for every case is often not 
> required and just overhead.

"Often"? On the contrary. It's the opposite. What's your use cases?
I have lots with composition of *many* function objects. We've
discussed some in earlier posts. "Overhead"? There is no overhead.
The compiler will optimize them away. Look at how proto does it,
for example. Zero overhead.

> Picking the simplest interface without these limitations will basically 
> yield what we are currently reviewing.

For the purpose of clarification, let me call the original
interface A and my proposal B.

Again:

* Transforming A to B requires minimal amount of coding. The smarts
   is already in the PP code. The cost is cheap.
* Building B on top of A requires Fusion or repeating the PP
   code all over again. The cost is high!

>>> 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".
>>
> 
> Implementing Steven's interface in terms of yours is not possible 
> without repeating the PP code.

But why do you want to do that? The interface I have encompasses
Steven's.

>>>> 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? 
> 
> Not only. More importantly to make it flexible.

And you are contradicting yourself if you say that. The interface
is far from flexible. You only got from A to B with the help of
another powerful library. It's not the switch_ library that's
flexible. It is Fusion that's flexible. I could implement my
desired interface with PP and Fusion more easily than going
through the half-baked switch_ under review.

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