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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-07 09:51:00

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

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

Agreed! The simpler, the better!

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

Yes, sometimes, but I think not here. At least, I don't think that is the
intention of Andrei's SmartPtr design.

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

Sorry, I didn't mean to be harsh. I was just trying to say that I think
boost is generally interested in flexibility and allowing unanticipated uses
to the extent that DSLs are ruled out for most of our work, and I think that
in particular a DSL-based approach may be inappropriate for a boost smart
pointer.

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

In the classic sense? None. On the other hand, I think you could look at the
system of defaults for selecting associated types used in the iterator
adaptor library as a kind of DSL. Note that the library also contains some
validation code for these types. The point is, it is reasonable to do this
because the set of associated types is closed (since they are given to us by
the iterator concepts), but the set of /behaviors/ is open. That's a
property I'd want to see in any smart pointer library as well.

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

I think you've lost the context of my remark. I was trying to explore the
question, "given that we all agree [;-)] that a DSL is too limiting for our
purposes, how can we make a policy-based design that is easiest to use?"

-Dave