Re: Combining Generative Programming and Policy-Based Design

From: timatdvc (timw_at_[hidden])
Date: 2002-02-22 14:01:57

--- In boost_at_y..., Mat Marcus <mmarcus_at_A...> wrote:
[...]
> I see two main differences between C&E-style GenVoca and policy 
> based design:
> 
> Policy based design (PBD)
>   * PBD uses Policies in two simultaneous roles, implemetation 
>     class templates and as a configuration DSL.
>   * PBD favors policies which don't communicate; collaboration is 
>     orchestrated by a "manager" class template (e.g. SmartPtr)
> 
> GenVoca
>   * GenVoca uses layers (generalized policies) for the 
>     implementation class templates. A separate configuration 
>     generator is used to parse the configuration DSL
>   * GenVoca offers (but does not require) the possiblity of 
>     communication between layers
> 
> There is an appealing simplicity in PBD: no configuration generator 
> is required. However, for some domains, the flexibility and 
> reusabiity offered by GenVoca probably outweighs the cost of the 
> additional required machinery. Of course, if you plan on writing a 
> configuration generator anyway then I see no advantage to using 
> policies instead of layers; in this case policies are merely the 
> degenerate case of a zero-layered design.
[...]

What I am suggesting is that by combining a configuration generator 
with PBD, the strenghts of each approach can be leveraged.  The 
simplicity of PBD makes it well-suited to implementing generic 
libraries.  The problem with PBD is that, as you pointed out, they 
serve 2 roles (configuration and implementation).  To use a policy-
based class or library, the user is responsible make low-level 
choices in the solution domain.  In a large library, the user 
shouldn't be required to know the details of the smart pointer used 
deep inside the library and how it should be configured.  To make a 
complex library (something with much coarser granularity than a smart 
pointer, e.g., a generic database library) useable, low-level 
policies should not be exposed to the end user.

Given a reasonable description of the likely uses of a domain 
library, one could effectively come up with a mapping between domain 
uses and the policies that best implement each possible use.  This is 
where a configuration generator would be perfect.  There may not 
necessarily be a one-to-one mapping from each configuration option to 
a given policy.  More likely, there would be a one-to-many 
relationship, with some interdependencies between the options.  A 
generator could hide these details from the user by selecting the 
appropriate policies for the provided options.  Because the 
configuration options would be in the language of the problem domain, 
a user can make (fewer and easier) decisions closer to the problem 
domain, thus making the library significantly easier to use.

One thing to keep in mind is that with either approach (PBD or 
GenVoca), the generator interface could be exactly the same in either 
case, so it really comes down to which method is easier to implement, 
or provides the greatest benifit.

From my perspective and experience, which I'll admit is limited with 
regard to GenVoca, PBD is one of the most straightforward and easily 
learned techniques for *implementing* generic libraries where a 
configuration generator makes *using* generic libraries easier.  In 
that respect, I think that combining them effictively can bring the 
best of both worlds.