Re: [boost] [switch_] Case Concept [ was Re: [Boost-users] formal review of Switch library...]

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-12 06:24:05

Joel de Guzman wrote:
> Joel de Guzman wrote:
> 
>> I'll try to come up with a complete interface proposal that
>> will encompass all use cases. It will be lightweight (no need
>> for extra infrastructure) and efficient. I believe it can
>> be done.
> 
> Ok, here's what I have for draft of the Case concept.
> I believe this is most crucial in the design of the
> switch_ as I proposed in a recent post. Comments,
> feedback, suggestions welcome.

AFAICT it looks very good. Here come some more thoughts:

> 
> Case Concept:
>      Specialization of unary Polymorphic Function Object that,
>      in addition to the requirements defined in Polymorphic
>      Function Object, encodes a list of labels in its type
>      necessary for switch dispatch.
> 
> Notation:
> 
>      c, c0, c1, ... cN       Case objects
>      C                       A Case type
>      I                       An MPL Integral Constant type
>      i                       An MPL Integral Constant object
>      N, First, Last          Integral constants
>      N0, N1, ...NN           A list of integral constants
>      f                       A unary function
>      case_c, case_range_c,
>      case_, default          Case factories
> 
> Valid Expressions:
> 
>      Expression              Semantics
>      ---------- 
> --------------------------------------------------------
>      C::labels               An MPL Sequence of Integral Constants

>      c(i)                    Function application

seemingly equivalent to

        c(I())                  Function application

(note: constant encoded in type). Maybe should be

        c.template apply<ResultType>(I())

instead (note: Passing in the result type).

>      case_<I>(f)             Returns a Case object with supplied
>                              MPL Sequence of Integral Constants.
>                              forwarding to the encapsulated function object f.

I think this one should be called 'cases' and 'case_' should take a 
single MPL constant, for consistency.

>      case_c<N>(f)            Returns a Case object with a single label N
>                              forwarding to the encapsulated function object f.
>                              Equivalent to: case_<mpl::vector_c<int, N> >(f)
>      case_c<
>          N0, N1, ...NN>(f)   Returns a Case object with a list of labels
>                              forwarding to the encapsulated function object f.
>                              Equivalent to: case_<mpl::vector_c<
>                                int, N0, N1, ...NN> >(f)
>      case_range_c<
>          First, Last>(f)     Returns a Case object with a range of labels
>                              forwarding to the encapsulated function object f.
>                              Equivalent to: case_<mpl::range_c<
>                                int, First, Last> >(f)

>      default_(f)             Returns a Case object with an empty labels list.
>                              forwarding to the encapsulated function object f.

>      c0, c1, ... cN          Returns a fusion sequence of Case objects

seemingly equivalent to

        (c0, c1, ... cN)

(note: Application of comma operator ;-)).

?! Why doesn't it just return another (compound) Case object and leave 
the Sequence an unspecified implementation detail...

> 
> 
> Notes:
> 
>    * While c0, c1, ... cN returns a fusion sequence, it does not
>      have to use Fusion. It can be a very simple cons list of
>      references to the actual arguments similar to the zero overhead
>      Proto expression tree. It must be compatible with Fusion though,
>      but that can be abstracted away.

...this way we'd have that abstraction specified, already.

> 
>    * case_c and case_range_c are simple shortcuts. The type of
>      integral constant is int. The actual type can be casted to
>      the actual switch parameter. I think this is safe, but a
>      variation is to have case_c and case_range_c expect the
>      actual type (like mpl::vector_c and mpl::range_c.). E.g.:
>      case_c<int, N>.

I prefer the former.

> 
>    * case_<I>(f) is equivalent to the original Steven interface.
> 

We could have this case swallow the index during function invocation, as 
for manual application we probably don't want to have it. I think it's 
typical and easy enough to just model the Case concept directly...

Regards,
Tobias