Need a policy for policies :) (was Re: [boost] Submission: Fixed-Capacity STL Containers Library)

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2002-02-07 19:04:32

It seems that the issue of whether to do a policy based design comes up
over and over again here at Boost. It is certainly an interesting issue to
discuss. There's lots of tension, not necessarily between people, but
between the various pro's and con's of the ideas. Andrei's described good
reasons for Boost to want policy based classes, and Matthias has described
good reasons for Boost to want the basic classes.

I'd like to see if we can resolve this meta-issue. I'm going to argue that
we should have both. That is, if someone submits a basic class and it
meets the usual Boost criteria, then we should go ahead and accept it.
Then, when someone submits the policy-based generalization of the class,
and it meets the usual Boost criteria, then we also accept that and
possibly deprecate the old basic class.

Ok, so what are the disadvantages of this approach? The main fear is that
once the policy class comes along, the basic classes will become baggage
that we can't get rid of. I'd argue that this isn't really a big problem
for Boost. One of the main purposes of Boost is to provide experience for
the C++ standard. Another way to say this is that we want to make mistakes
at Boost so that we don't have to make mistakes in the C++ standard. Boost
doesn't have to be as stable as the C++ standard. Boost hasn't promised to
be 100% stable and backward compatible.

So what are the advantages of this approach? First, users get the benefit
of the basic class right away. This is of significant importance. Second,
real-world experience with the basic class will help out when the
policy-based class is being designed. So we'll end up with a better
policy-based class in the long run.

Best Regards,
Jeremy

On Fri, 8 Feb 2002, Matthias Troyer wrote:

troyer> Hi Andrei,
troyer>
troyer> > I am not familiar with the internals of the boost review process (other
troyer> > than
troyer> > it makes the submitters buy rope and soap), but on the face of it, why
troyer> > invest time in something that you know right off the bat is not what you
troyer> > want? Wouldn't that time be better invested in figuring out a good
troyer> > design?
troyer> > Today's approved stuff transforms into tomorrow's solidified lava that
troyer> > you
troyer> > hate but you can't throw away.
troyer> >
troyer> > I do appreciate the work invested in fixed_vector, but, with all due
troyer> > respect, I think the design doesn't shot in the right direction, and
troyer> > besides, the implementation has issues of which rework tantamounts to a
troyer> > complete rewrite.
troyer>
troyer> I understand what you are aiming at, and agree completely with you that
troyer> a good policy-based vector implementation is highly desirable. However,
troyer> I myself have definite needs of such a container right now, and could
troyer> use the fixed_capacity_vector for those now. On the other hand the
troyer> policy based vector is at the moment an idea without any plans for a
troyer> concrete implementation? Who is going to write one that is optimal in the
troyer> near future? Do you have any plans for writing this? If I have the choice
troyer> between a concrete but limited class to use now, or an idea for a better
troyer> and more flexible class that does not exist yet, I prefer the existing
troyer> one.
troyer> After all I need to get work done and cannot always wait for the nicest
troyer> solution and don't mind rewriting a few lines in my codes in the future
troyer> if there's a better solution a couple of years from now.
troyer>
troyer> Matthias

----------------------------------------------------------------------
 Jeremy Siek                          http://php.indiana.edu/~jsiek/
 Ph.D. Student, Indiana Univ. B'ton   email: jsiek_at_[hidden]
 C++ Booster (http://www.boost.org)   office phone: [phone]
----------------------------------------------------------------------