Re: [boost] [lib maintainers] Pleaseidentifyheadersinboost-root/boost

From: David Abrahams (dave_at_[hidden])
Date: 2007-11-18 13:49:50

on Sun Nov 18 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> David Abrahams wrote:
>> In general, no, it has not been the case.  This may not be a perfect
>> arrangement, but with very few exceptions:
>>
>> * Core libraries whose documented public interface fits in just a few
>>  headers and a few pages of documentation have been able to put all
>>  their public headers in boost/ and their components in boost::.
>
> Ahh - "Core libraries" - perhaps that's the missing link.  So
> static_assert.hpp would be a "core library" 

Yes.

> but static_warning.hpp
> would be a ..... non-core library?

No, it's not a Boost library at all unless it has ever passed review.

>> * 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
>
> Which is another problem in my view.  If they're meant to be used
> by more than one library they should have a documented and tested
> interface.  Otherwise, they should be in the particular library even
> at the cost of code repetition.

Irrelevant; we can talk about that policy idea in another thread.

>> I explained most of this in
>> http://lists.boost.org/Archives/boost/2006/05/105195.php
>
> and I responded at the time.

In approximately the same unhelpful way as you are responding now.

> well, as far as pfto.hpp is concerned, I concede an error in
> foresight on my part.  I envisioned that as a general fix for those
> compilers which failed to correctly implement partial function
> template ordering and thought it orthogonal to the serialization
> library as a whole.  As the whole serialization library was subject
> to review - including this point and no objection was raised at the
> time - i left it there.

I am neither criticizing your foresight, nor whatever honest mistakes
you may have made in the past.  I _am_ criticizing the way you react to
polite requests to change what you've done.

> BTW it IS documented and its NOT really part a part of serialization
> per se.

Until it is reviewed as a separate library, it is part of
serialization.

>>> So rather than saying that authors have refused to follow "standard
>>> practice", it would be more accurate to say that...
>>
>> Nobody said that.
>
> from http://lists.boost.org/Archives/boost/2006/05/105200.php

That link does not seem in the least to refute my claim.

>>> These unconventional moves are at best confusing for users and other
>>> maintainers. The Boost source base is hard enough to control without
>>> library authors inventing their own new rules for organizing things.
>
>
>>What I said was that some people have ignored
>> direct (public and private) appeals from moderators to bring their
>> headers into conformance with the standard practice, and that is
>> exactly correct.
>
> a) There is no stated "standard practice" so it cannot be correct.

Look up "practice" in your dictionary; it means "custom."  A "standard
practice" does not have to be documented.  To wit
http://www.answers.com/topic/practice says, among others:

  A habitual or customary action or act. Often used in the plural:
  That company engages in questionable business practices. Facial
  tattooing is a standard practice among certain peoples.

> b) There is no obvious "convention" in many areas

You've been told what the convention is on several occasions.

> c) Authors are left to try to decipher intent from the current
> hodgepodge.  I believe that all authors have tried to do this

Anyone who is curious knows where to ask.  It would certainly be
better to document it.  Lack of documentation doesn't make it alright
for library authors to disregard requests to conform, especially when
the requests come from (multiple) moderators.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com