Re: [boost] Library namespace guidelines

Subject: Re: [boost] Library namespace guidelines
From: Neil Groves (neil_at_[hidden])
Date: 2009-07-05 11:09:28

On Sun, Jul 5, 2009 at 2:44 PM, Steven Watanabe <watanabesj_at_[hidden]>wrote:

> AMDG
>
> Neil Groves wrote:
>
>> I have read both the "Library Requirments and Guidelines" and specifically
>> examined the "Boost Header Policy" and the section on naming consistency
>> but
>> have yet to understand how I should choose to use namespaces for the next
>> version of Boost.Range, that incorporates the accepted Boost.RangeEx
>> proposal.
>>
>> It feels indecent and naughty (in a bad way!) to be putting the library
>> into
>> the top-level boost namespace. More importantly I am concerned that
>> general
>> functions such as "find" will clash when combined with other boost
>> libraries
>> both now and in the future.
>>
>> Would the ideal scenario for new libraries be to have a library related
>> namespace under boost in a manner akin to Boost.Filesystem?
>>
>>
>
> Yes.  Most libraries have this.
>

Thanks. I noticed that most libraries are working in this manner. I also
note that there are exceptions to this almost De Facto standard. There
doesn't seem to be a clear developer policy on this specific issue. I think
that perhaps an update to the naming convention guidelines might be sensible
to reflect this way of working. I also am concerned that we (Boost
developers) are perhaps not maintaining all of our libraries to have a
consistent namespace naming convention. I am hoping that I am simply being
ignorant. Is there, for example, an effort scheduled to remove the using
algorithm::find declaration from Boost.Algorithm? Is there even an intent to
do so?

>
>
>  Is there already a strategy that is well-known that I am ignorant of?
>> Is there an existing strategy to migrate libraries that pollute the
>> top-level boost namespace that maximises backward compatibility?
>>
>>
>
> Using declarations can help.
>

I gave the using directive solution some thought and this seemed to be a
reasonable approach. I thought a using declaration would mean that my
namespace version of for example, "find" would be used in preference to a
"find" function in boost::algorithm that had been brought into the boost
namespace through the using directive. I'm not entirely sure that this is an
acceptable solution, since this still breaks existing code. The "find"
example is a genuine motivating example since it is in the Boost.RangeEx
proprosal and is already present in Boost.Algorithm. Ideally I would be able
to make all of the code in boost::range and ther sub-namespaces, while
making the old functions accessible through the boost namespace as they used
to be. I'm finding a solution elusive since I believe that using
declarations do not provide backward compatibility, and the using directives
would mean that I would need to put new and old range code into different
namespaces to avoid pulling the new functions into the boost namespace.

Do other boost developers agree that the using declarations are the optimal
boost-approved way to provide backward compatibility while migrating to a
new namespace? Is the strategy to leave the using declaration inplace for
one or two point releases before removing the using declaration?

>
>
>  Any assistance with this matter would be greatly appreciated.
>>
>
>
>>
> In Christ,
> Steven Watanabe
>

Many thanks for your time and assistance,
Neil Groves

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>