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