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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-11-18 00:19:52

Joel de Guzman wrote:
> Robert Ramey wrote:
>> A little greping reveals the following headers which would seem to
>> violate "standard practice".  I've tried to exclude those which are
>> "convenience headers" which do nothing but call a bunch of includes
>> for some library.
>>
> [...]
>>
>> Lots of these have been there for years.  So I'm not sure where the
>> idea that there exists a "standard practice" comes from.
>
> First, define "standard practice". I can't say that all the files you
> listed violates the "standard practice" if we haven't defined it yet.

aaaaaaaa - that's my point. There has never been any "standard
practice defined"

>> 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.

> 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?

>> 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.

>> 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.

>> 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.

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
index.  Then there is utility.hpp which is a convenience header
for a group of otherwise separate library - not including
mult-index.

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.

Robert Ramey