Re: [Boost-users] formal review of Switch library ends tomorrow (Wednesday, January 9th) - reviews needed

From: Steven Watanabe (steven_at_[hidden])
Date: 2008-01-10 21:38:02

AMDG

Joel de Guzman <joel <at> boost-consulting.com> writes:

> Single function:
> 
> I'm a strong advocate of smaller is better. Modularity matters.
> Big classes (or in this case function objects), metaprogram blobs
> (i.e. traits), humongous enums, and all such sort of dinosours 
> are best avoided. They are convenient up to a certain extent and
> becomes unmanageable beyond a certain limit.

When it's being managed by humans sure.  When the creation
of the whatever is automated and it's never used by humans
directly it doesn't matter much.  The big function object
you refer to has a single conceptual responsibility.  It isn't
a blob any more than a fusion sequence used for the same purpose.

> In all of my use cases, I have N functions that are provided
> elsewhere and I have no control over (e.g. parser functions).
> I insist that this is the more common use case. Grouping
> them into a single big struct is an unnecessary and cumbersome
> step.

It may be more common.  What I know for certain is that it's
slightly easier to implement my interface in terms of yours
than the other way around.

> Still, if people insist, I outlined a way to convert the big
> function object to smaller 'bound' objects, in another post.
> Just bind 'em into smaller function chunks.

That's true for your use cases.  For cases where
you have a runtime integer which you need to convert
into a compile time integer, which is then used to index
into an mpl sequence for instance (as in variant)
separate function objects are pointless.  I don't want
to relegate this usage to the side just because you
don't happen to need it.  There are enough use cases
that it needs to be considered, IMO.  Another example is for
finite state machines.  Also, at one point I was considering
a multiple dispatcher that involved a switch.

In Christ,
Steven Watanabe