Joel de Guzman wrote:
Tobias Schwinger 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
Joel de Guzman wrote: 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