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

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-12-02 21:28:04

Robert Ramey wrote:
> Joel de Guzman wrote:
> 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).
> 
> The case of codecvt_utf8 is interesting in his regard.
> 
> In the course of development, we ended up with
> one copy in the serialization library and another
> identical copy in the program options library.
> Strenuous objections were raised about this.  So
> it was "moved" to boost/detail - only because
> of these objections.  It was never reviewed as
> a separate entity.  It had its own tests and documentation
> page - but there was no place to put this
> in boost/detail.   Perhaps boost/utility would
> be better - but then it would have had to suffer
> a review and no one wanted to take ownership.
> And recently I discovered that I forgot to take it
> out of the serialization library in any case.   So
> a strict adherence to the proposed policy will
> result in duplicated code - not the end of the world -
> but some are going to object to that.
> 
> As an aside, I noticed a talk titled something
> like "hidden boost gems" where codecvt_utf8
> was specifically mentioned.  So some things end
> up being quasi-official by default.

What's wrong with having one of the interested parties host it?
What's wrong with having it in, say, boost/serialization/support
and have it included by the other library using it? Sure, that
is not ideal, but that practice ultimately avoids having boost
detail crowded.

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