Re: [boost] Loki SmartPtr study: Policy orthogonality issues

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-07 08:59:20

----- Original Message -----
From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>

> From: "David Abrahams" <david.abrahams_at_[hidden]>
> > The use of orthogonal policies certainly has a conceptual cleanliness
which
> > I favor. On the other hand, breaking things up into tiny pieces also
gives
> > users more details to worry about, so it isn't clear to me which
approach is
> > actually simplest for users.
>
> What you want is to separate the way the smart pointer is implemented from
the
> way in which the user specifies a smart pointer configuration. This is all
> conceptually explained and demonstrated in C&E. In other words:
>
>   Specification in a Configuration DSL -> Generator/Translator -> Finished
> Component Configuration
>
> When you separate the way the user specifies the configuration, it really
> doesn't matter, from the users perspective, that the implementation is
broken
> into dozens of tiny components. You can also have multiple generators for
the
> same set of implementation components.

That's only true to the extent that you buy into the C&E theory that your
important users are low-skilled factory workers that need a highly
simplified (and restricted) DSL in order to interact with your components.
Taken to an extreme, you end up with a set of components which can be
configured only in exactly the ways that the author has already envisioned.

To be fair, I should say that I spoke to Kristof about this and he said
something like "oh, sure, you just do that at an outer layer to make it easy
for novice programmers to configure your components, but you probably want
another layer below the DSL which allows more flexibility". So it isn't
really C&E theory that the next layer doesn't matter, but they don't really
focus on it either.

In any case, I don't think a configuration DSL is an appropriate approach
for us. The beauty of policy-based designs is that they don't restrict the
universe of final products in the same way that DSLs tend to. I do think
it's still important to ask which policy-based designs are easiest to grasp
and use. I have first-hand experience with the Iterator Adaptor library
which shows that its Policy Adaptor approach (which was inspired by Andrei's
work, I might add) is highly accessible. I've seen programmers with less
than 6 months of C++ look at an example use of the library and start
inventing their own specialized iterator adaptors, without even reading the
documentation. Of /course/ I am biased, but I find the approach used by
SmartPtr using five template template parameters to be much more daunting.

-Dave