Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>

Subject: Re: [boost] Boost policy for putting headers in boost/ Was: #3541 Support <boost/ptr_map.hpp>
From: Joel de Guzman (joel_at_[hidden])
Date: 2009-10-23 19:22:04

Stewart, Robert wrote:
> Joel de Guzman wrote:
>> Stewart, Robert wrote:
>>> How about "_"? Is "_.hpp" legal in all supported filesystems? Since we're talking
>>> about libraries, and not applications, how about "main.hpp?" "main" is still very
>>> short and would be consistent.
>> To be honest, I find the lib/main.hpp idea not bad at all (except for the extra
>> typing involved vs. lib.hpp). However, following
> 
> lib.hpp works fine, too.
> 
>> existing practice, and not breaking existing code, IMO, far outweigh the problem you 
>> have with tab completion: that can never be a valid rationale for breaking existing
>> code.
> 
> I agree.  However, the tab completion problem merely highlights the noisiness of the
> directory plus like-named header approach. 

It's noisier, true. If we were to rewrite Boost all over again, or if we
were to restart from 1999, I'd vote for something unified, similar to your
suggestion. But this is 2009. It's too late for that. We can't break the
code base.

> That also affects directory listings and directory navigation dialogs.

Hmm, never had a problem with that. How is that a problem?

>> Fusion simply follows existing practice and extends it to the next level of
>> modularity. There were two existing practice at the time when I wrote fusion:
>> 
>> lib/ lib.hpp
>> 
>> and
>> 
>> lib/ lib/lib.hpp
>> 
>> I find the latter redundant. I chose to follow the first.
> 
> IOW, there isn't one approach now.  If we adopt a single approach, some code will
> break.  Granted, in the latter case, lib/lib.hpp can be copied to lib.hpp and thus make
> it like the former, but at some point, lib/lib.hpp should be removed, and that will be
> a breaking change.

Here's my thoughts on this:

* IMO, we can't break the code for just the reason of wanting a cleaner
   include structure. That is simply not acceptable.

* We can't add yet another header policy. Doing so will only add to the
   confusion.

* Newer libraries should pick only one style, and that style, IMO is the
   fusion style. No, I did not invent that. Since day one, that has been
   the predominant header organization style of boost. We should dissuade
   newer libraries from using the other header style (libname/libname.hpp).

   Again, this should apply to newer libraries only. We can't gratuitously
   break existing libraries just for the sake of neatness.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net
http://www.facebook.com/djowel
Meet me at BoostCon
http://www.boostcon.com/home
http://www.facebook.com/boostcon