Boost namespace abreviations

Hi there, I just wanted to hear the boost community's thoughts on abbreviating boost's namespaces. According to Boost's library naming conventions (http://www.boost.org/development/requirements.html#Naming_consistency) this is strongly discouraged, and with good reason -- having clearly (and consistently) named namespaces is a good thing! Having used boost for a (mere) couple of years now, though, I've started to find its namespaces a bit unwieldy. I try to avoid going "using namespace" (for a few reasons, nicely summarised here: http://dev.lsstcorp.org/trac/wiki/DiscussCodeStandards) and I can't bring myself to go down the route of announcing to the compiler that I will be "using ..." specific symbols from whichever namespace either. So I am left with having to explicitly specify the namespace of each symbol, like this: std::cout << std::setw( 2 ) << std::setfill( '0' ) << hours; While this requires more typing, I prefer it to the alternatives. As a boost user though, I find this becomes a bit more of a pain. Boost's namespaces, whilst well named, are a lot to keep typing out! Here's a quick example: boost::posix_time::time_duration foo = boost::posix_time::hours(2); Multiply this by a thousand lines of boost-using code and you've got a lot of typing! I wondered if there would be any interest in a boost abbreviations header that, if included, would provide abbreviated names for boost's namespaces. Something along the lines of a boost/abrv.hpp: // this is an incomplete example namespace bst = boost; namespace boost { namespace gd = gregorian; namespace pt = posix_time; namespace dt = date_time; } This would allow the developer to shorten the above example code to bst::pt::time_duration foo = bst::pt::hours(2); in this case saving a full 18 characters! Multiply this by 1000 lines of code and you may save some finger-ache. What I'm proposing sounds terrible, I know, but if you consider that users would "opt-in" to this by including the abbreviations header (meaning it wouldn't affect existing users), I wondered if there would be any merit in it? I'm expecting a lot disapproval to this idea, but I thought I'd ask what people think anyway. Please don't shoot me down too much -- this is my first post to the boost mailing list! :o) Regards, Tim. -- edam - www.waxworlds.org/edam

edam wrote:
Hi there,
I just wanted to hear the boost community's thoughts on abbreviating boost's namespaces. According to Boost's library naming conventions (http://www.boost.org/development/requirements.html#Naming_consistency) this is strongly discouraged, and with good reason -- having clearly (and consistently) named namespaces is a good thing! Having used boost for a (mere) couple of years now, though, I've started to find its namespaces a bit unwieldy.
<snip> What I'm proposing sounds terrible, I know, but if you consider that users would "opt-in" to this by including the abbreviations header (meaning it wouldn't affect existing users), I wondered if there would be any merit in it? I'm expecting a lot disapproval to this idea, but I thought I'd ask what people think anyway. Please don't shoot me down too much -- this is my first post to the boost mailing list! :o)
I don't see the point. I can type namespace fs = boost::filesystem; at most points of the source file and suddenly I have a very handy fs shortcut for that big, ugly namespace. I think having a special header for this is overkill. And "bst" is just ugly. Sebastian

edam-2 wrote:
Hi there,
I just wanted to hear the boost community's thoughts on abbreviating boost's namespaces. [...] I wondered if there would be any interest in a boost abbreviations header that, if included, would provide abbreviated names for boost's namespaces. Something along the lines of a boost/abrv.hpp:
// this is an incomplete example namespace bst = boost; namespace boost { namespace gd = gregorian; namespace pt = posix_time; namespace dt = date_time; } [...]
I think that using namespace aliases is just fine, but only in the context of a particular program, where you are in control of possible name clashes. Providing a general purpose abbreviation does not make sense precisely because names are chosen that long to avoid clashes!! For instance, if you google for "namespace bst": http://tinyurl.com/595596 you get two uses of this namespace name for things other than aliasing boost.
What I'm proposing sounds terrible, I know, but if you consider that users would "opt-in" to this by including the abbreviations header (meaning it wouldn't affect existing users), I wondered if there would be any merit in it? I'm expecting a lot disapproval to this idea, but I thought I'd ask what people think anyway. Please don't shoot me down too much -- this is my first post to the boost mailing list! :o)
I hope you'll get by through this post :) Seriously, don't hesitate to keep contributing to the list. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo -- View this message in context: http://www.nabble.com/Boost-namespace-abreviations-tp20725992p20726147.html Sent from the Boost - Dev mailing list archive at Nabble.com.

I prefer the method used in the filesystem examples: Namespace fs = boost::filesystem; Sent from my Verizon Wireless BlackBerry -----Original Message----- From: edam <edam@waxworlds.org> Date: Thu, 27 Nov 2008 18:51:03 To: <boost@lists.boost.org> Subject: [boost] Boost namespace abreviations Hi there, I just wanted to hear the boost community's thoughts on abbreviating boost's namespaces. According to Boost's library naming conventions (http://www.boost.org/development/requirements.html#Naming_consistency) this is strongly discouraged, and with good reason -- having clearly (and consistently) named namespaces is a good thing! Having used boost for a (mere) couple of years now, though, I've started to find its namespaces a bit unwieldy. I try to avoid going "using namespace" (for a few reasons, nicely summarised here: http://dev.lsstcorp.org/trac/wiki/DiscussCodeStandards) and I can't bring myself to go down the route of announcing to the compiler that I will be "using ..." specific symbols from whichever namespace either. So I am left with having to explicitly specify the namespace of each symbol, like this: std::cout << std::setw( 2 ) << std::setfill( '0' ) << hours; While this requires more typing, I prefer it to the alternatives. As a boost user though, I find this becomes a bit more of a pain. Boost's namespaces, whilst well named, are a lot to keep typing out! Here's a quick example: boost::posix_time::time_duration foo = boost::posix_time::hours(2); Multiply this by a thousand lines of boost-using code and you've got a lot of typing! I wondered if there would be any interest in a boost abbreviations header that, if included, would provide abbreviated names for boost's namespaces. Something along the lines of a boost/abrv.hpp: // this is an incomplete example namespace bst = boost; namespace boost { namespace gd = gregorian; namespace pt = posix_time; namespace dt = date_time; } This would allow the developer to shorten the above example code to bst::pt::time_duration foo = bst::pt::hours(2); in this case saving a full 18 characters! Multiply this by 1000 lines of code and you may save some finger-ache. What I'm proposing sounds terrible, I know, but if you consider that users would "opt-in" to this by including the abbreviations header (meaning it wouldn't affect existing users), I wondered if there would be any merit in it? I'm expecting a lot disapproval to this idea, but I thought I'd ask what people think anyway. Please don't shoot me down too much -- this is my first post to the boost mailing list! :o) Regards, Tim. -- edam - www.waxworlds.org/edam _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

edam wrote:
bst::pt::time_duration foo = bst::pt::hours(2);
But why is time_duration in the binary_search_tree::patricia_trie namespace? Sorry couldn't resist. This seems like an exercise best left to the user so that projects can define their own abbreviations that don't clash with their domain names. -- Michael Marcin
participants (5)
-
edam
-
Joaquin M Lopez Munoz
-
Michael Marcin
-
raindog@macrohmasheen.com
-
Sebastian Redl