Re: [boost] [lib maintainers] Please identifyheadersinboost-root/boost

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-11-18 02:30:16

Robert Ramey wrote:
> Joel de Guzman wrote:

>>> In my particular case, I had a need for some things like
>>> static_warning and strong_typedef which didn't exist.  I didn't put
>>> them where they are currently found by accident.  I knew they didn't
>>> fit in the serialization library
>>> and it seemed they were very similar to other files in the above
>>> list.  I made
> 
>> So, if I decide that some parts of spirit (a lot! e.g. multi_pass
>> iterator) is useful outside spirit and does not really belong in
>> spirit, I'm free   to put that outside the spirit sphere and into boost?
> 
> Up until now that's been the case.

Well, this IMO has got to stop.

>> Why not put it in serialization "misc" then? In my libraries, we have
>> such utilities in "support".
> 
> To make such a move at this point it would be an interface breaking change.
> How much code would break if boost/shared_ptr (and boost::shared_ptr etc)
> is changed at this point? Do you really think that all these changes
> should be made now?

No, of course not. But was has boost/shared_ptr got to do with this?

>>> The serialization library was reviewed TWICE and no one ever
>>> mentioned this.
> 
>> It's unfortunate that this has gone unnoticed from 2 reviews. Perhaps
>> it didn't matter much at the time, or simply it slipped from the radar
>> screen. Nevertheless, that does not make it right.
> 
> I doubt it went unnoticed.  I suspect that it was percieved as
> the "standard practice" at the time.

It went unnoticed at least for me. I would have objected otherwise.

>>> So rather than saying that authors have refused to follow "standard
>>> practice", it would be more accurate to say that there has been
>>> no definition of "standard practice" and many authors have
>>> interpreted it in the most logical way given the current situation.
> 
>> Agreed. I'm not quite sure about the "most logical" way though.
>> For me, it's pretty clear that free-for-all addition of just about
>> anything in the boost root directory and the boost namespace
>> is not good. There are namespaces and subdirectories.
> 
> As I said, I don't object to establishing a "standard practice".
> But it's really annoying to be characterised as being unwilling
> to respect a "standard practice" when no such thing has
> been established.

I don't think anyone is pinpointing you as unwilling to respect
"standard practice".

>>> While we're at it, there is also the question of boost/utility.
>>> Clearly there is useful stuff in there.  I've used it myself.  But
>>> non of it has any documentation nor separate tests as far
>>> as I can tell.  (ucs code cvt facet is tested and documented
>>> in the serialization library).
> 
> My mistake - I meant boost/detail.
> 
>> Really? enable_if, addressof, result_of, at least, have docs
>> and tests.
> 
> LOL - yeah but the directory structure doesn't respect
> the practice used by other libraries.  And that's only 3
> modules about of
> 
>> I do not see ucs code cvt facet there. What am I
>> missing?
> 
> the header is in boost/detail.  It should have gone into
> boost/utility but there was a hassle because it wasn't reviewed.
> Before that the same code was in multiple libraries
> and there was an objection to that.  No matter what -
> we can't get a break.  So it went into boost/detail
> and guess what - there is no place to put documentation
> or tests for anything in boost/detail.

Yes, because boost/detail is not public API and the
stuff there is implementation detail.

> Now I see that boost/utility/multi-pass has a documentation
> page but no way to get to by following the links in the documentation

I'm lost again. boost/utility/multi-pass is non-existent.

> index.  Then there is utility.hpp which is a convenience header
> for a group of otherwise separate library - not including
> mult-index.

If a particular utility is useful for many libraries, then one of
the libraries can host it prior to it getting reviewed independently
and becoming a full-fledged boost citizen. That's the policy that
we've been following with the synergy between xpressive and spirit,
for example. Case in point: fusion, proto, multi_pass, and many more
smaller utilities and stuff. fusion was hosted by spirit before it
was reviewed and was used by xpressive even before spirit did. Now
that fusion passed the boost review, it has become a full-fledged
boost citizen.

> So any kind of "standard practice" should also
> normalize all of this as well.  Fine by me.
> 
>>> I think the only practical thing to do at this point is
> 
>>> a) debate and establish a policy for using boost/ and boost::
> 
> and boost/detail and boost/utility
> 
>>> b) enforce it for new additions
>> Encourage developers of libraries in violation of the policy
>> to do the right thing.
>>
>>> c) hope that over time the current contents migrate out
> 
> So I guess we're in agreement.

That's a good start.

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