Re: [boost] [lib maintainers] Please identify headersinboost-root/boost

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-11-17 23:07:08

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.
I am not saying that your files are violations of the practice too.
I just said that it is somewhat discomforting. I am not pinpointing
serialization.

> 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? That does not make
sense. So what's the need for fast-track reviews if I can easily put
anything into the root directory and into the main boost namespace?

> a manual page for each of them.  There wasn't a convenient place to put
> the documenation so I left it as "misc" in the serialization documentation.

Why not put it in serialization "misc" then? In my libraries, we have
such utilities in "support".

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

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

> Now if one want's to define a "standard practice" that's fine.
> And clearly boost is a lot bigger than it used to be so the best
> practice may well be different than it used to be.  But it has
> to be recognized that this is a whole new thing.  And its not
> clear what that new thing should be?
> 
> 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).

Really? enable_if, addressof, result_of, at least, have docs
and tests. I do not see ucs code cvt facet there. What am I
missing?

> I think the only practical thing to do at this point is
> 
> a) debate and establish a policy for using boost/ and boost::
> 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

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