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 09:30:31

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!

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.

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

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

Implementing Steven's interface in terms of yours is not possible 
without repeating the PP code.

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

Regards,
Tobias