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

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-12-01 02:24:08

Robert Ramey 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.  However,
> 
> There is no place for documentation of these things.  So there
> is no guarenteed interface.
> 
> And of course no separate tests.
> 
> 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.
> 
> 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.  I realise some might find this bothersome, but its
> much better the the current situation.

Good points. I for one have not placed anything in boost detail.
I just based the text on current standard practice, but to be
honest, I too don't like free for all additions into boost detail.
It too has a big chance of pollution related problems as Boost
grows even bigger.

My opinion on this is to keep the boost/detail *solely* for
core libraries use. For non-core libraries, it is always better
to use boost/<library>/detail and boost::<library>::detail
as many libraries are already doing. If they need to be used
by other libraries, then my thinking is that they ought not to
be in detail, but rather, hosted by a parent library, just
like that suggested in the last item in the list of current
"practices". Then, the natural place for its documentation is
the host library (e.g. The proto docs are currently in xpressive,
the pre-review of fusion was once in spirit).

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net