Re: [boost] [RFC] Header/namespace policy draft

From: David Abrahams (dave_at_[hidden])
Date: 2007-12-01 09:04:11

on Sat Dec 01 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> Joel de Guzman wrote:
>
>>> * Un-reviewed implementation details of libraries have been placed in
>>>  boost/detail if they need to be used by other libraries and a
>>>  subdirectory of boost/<libraryname>/ otherwise. Their documented
>>>  public components are placed in boost/detail and namespace
>>> boost::detail.
>>>
>
> I think the current situation is a little problematic.
>
> If there in boos/detail, presumable its because they might be
> useful accross more than one library.  

Not usually.  Usually it's because they *have* been useful across more
than one library.  In general, nobody sticks stuff in boost/detail
just because they think it might have a use elsewhere.  Components
migrate there.

> However,
>
> There is no place for documentation of these things.  

Sure there is.  Comments work.

> So there is no guarenteed interface.
>
> And of course no separate tests.

Not necessarily.  I always write tests for my library's implementation
detail components.

> No guarentee that the interface won't change - after all
> its an implementation detail.  So it can change without
> warning an break other libraries.
>
> So, one has a lot of reservations about depending upon these
> modules.  On the other hand, they have proved very useful so for the
> sake of expediency they're going to get used - leading to surprise
> breakages.

That's more of a theoretical problem than a real one. It has never
been an issue in the past.  Most people realize that once a component
moves into boost/detail, other people may be depending on it, so they
make an effort to coordinate if there are any breaking changes (which,
to my knowledge, there have never been in a boost/detail component).

> So I think those things that have been going to boost/detail should
> just go into boost / utility.  Approval for this would be part of
> the review process for the library which needed them.  

Implementation details get invented and shared as part of a library's
evolution, so that would never work

> I realise some might find this bothersome, but its much better the
> the current situation.

I don't see why.  A little common sense is all it takes to make this
work out, and it has worked very well so far.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com