Boost logo

Boost Users :

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-01-11 11:11:11


Joel de Guzman wrote:

>>> 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.
>
> Ok. Good point.

Ok, if this is the intent, then it should be clearly mentioned in
the docs. But let me ask then, for the sake of discussion, how
do you intend to build the struct of overloaded operator()s?
If that is the intent, then why does the library not provide
the necessary tools to do that?

Now, you mentioned a fusion sequence. If the intent is for the
big function object to be built, why is that scheme any better
than simply using a fusion structure in the first place? All
the mechanisms for building the container of cases are already
in place. Why invent another scheme?

Regards,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net