On Sun, Jul 5, 2009 at 2:44 PM, Steven Watanabe <watanabesj@gmail.com>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