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

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2002-01-07 09:27:29

From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
> > From: "David Abrahams" <david.abrahams_at_[hidden]>
[snip]
> > 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.

Practically every programmer uses "simplified" interfaces to many kinds of
complex systems all the time. Programmers don't have to be experts in every
system they use. I often use simplified interfaces to systems that I myself
have designed and written. I rarely need every feature of a complex system.

> 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.

And sometimes that is exactly what is wanted. For instance, if I were writing
components for mission critical software, I wouldn't want it to be configured
in ways that I have not intended.

> 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.

You have interpreted my comment much too harshly. If you build a software
system in which some layer doesn't matter, then you should get rid of that
layer. However, I rarely care or know about most of the software layers that I
use indirectly.

> In any case, I don't think a configuration DSL is an appropriate approach
> for us.

How many configuration DSL based systems have you designed, implemented and
used?

> I find the approach used by
> SmartPtr using five template template parameters to be much more daunting.

I have never advocated the use of template template parameters.