algorithms namespace
Hi, During the review of the string algorithm library, an issue was raised about the namespaces for algorithmic libraries in the boost. The issue has not been sufficiently resolved, and I would like to bring it up to the discussion again. Current proposal looks like this: boost - algorithm - common algorithm related stuff - string - string algorithms - container - container algorithm etc. Although this seems clear enough, there are some open questions. 1.) Namespace path is quite long. It is not really reasonable to await from a user to always type boost::algorithm::string::trim. "using namespace" directive is not always a viable solution. And even if it would be, a user would have to specify several of them to use whole algorithm library (what could not so uncommon, in my opinion) Namespace aliasing is one of possible solutions, but again, one would have to alias every algorithm sub namespace. 2.) It is not clear if what should go into boost::algorithm namespace and what to more specific ones (like boost::algorithm::string). This is specificaly an issue of algorithms, that logicaly belong to various categories. An example would be "all" algorithm. It is generic enough to not be contained in the string library. But on the other hand, together with classification predicate, it is essencial for the string processing. Should it go to algorithm::string, algorithm::container, plain algorithm or somewhere else? Suggestions: 1.) One possibility would be to relieve the idea of algorithm subnamespace and put everything into boost::algorithm namespace. Benefit would be simplier namespace specification and less suprises about where is a particular algorithm. Disadvantage can be a possibility of nameclashes and poluted namespace. 2.) Another option would be to use subnamespaces, but to propagate user-level interface names to boost::algorithm using "using" directive. In this alternative, there is still an open question (2). (i.e. to define more precisely the policy for putting algorithms/classes into namespaces) 3.) Let everything in subnamespaces and identifying the problem(1) as irelevant. 4.) Some other idea, I don't know yet about. Your ideas/optinions are welcome. Regards, Pavol
Pavol Droba wrote:
It is not really reasonable to await from a user to always type boost::algorithm::string::trim.
Maybe it could help a little bit to replace 'algorithm' by 'algo' and 'string' by 'str'. IMHO, also shorter namespaces like 'boost::filesystem' have the problem of beeing too long to be used on every access. Long typenames like boost::filesystem::directory_iterator have a very high capability to make the code unreadable very quickly. Stefan
On Wed, 18 Feb 2004, Stefan Slapeta wrote:
Pavol Droba wrote:
It is not really reasonable to await from a user to always type boost::algorithm::string::trim.
Maybe it could help a little bit to replace 'algorithm' by 'algo' and 'string' by 'str'.
IMHO, also shorter namespaces like 'boost::filesystem' have the problem of beeing too long to be used on every access. Long typenames like boost::filesystem::directory_iterator have a very high capability to make the code unreadable very quickly.
What's wrong with namespace fs = boost::filesystem; ? It's not like a template, where we don't have a good aliasing mechanism. Doug
Douglas Paul Gregor wrote:
On Wed, 18 Feb 2004, Stefan Slapeta wrote:
Pavol Droba wrote:
It is not really reasonable to await from a user to always type boost::algorithm::string::trim.
Maybe it could help a little bit to replace 'algorithm' by 'algo' and 'string' by 'str'.
IMHO, also shorter namespaces like 'boost::filesystem' have the problem of beeing too long to be used on every access. Long typenames like boost::filesystem::directory_iterator have a very high capability to make the code unreadable very quickly.
What's wrong with
namespace fs = boost::filesystem;
?
I would turn the question around and ask what's wrong with boost::fs (and when I see boost I think std). I've never understood the rationale behind long namespace names. Yes, I can alias filesystem to fs myself. But when all of your users alias filesystem to fs, and you find yourself doing the same in documentation, examples, tests, and in your own code, then perhaps it should have been named fs in the first place.
On Wed, 18 Feb 2004, Peter Dimov wrote:
Douglas Paul Gregor wrote:
On Wed, 18 Feb 2004, Stefan Slapeta wrote:
Pavol Droba wrote:
It is not really reasonable to await from a user to always type boost::algorithm::string::trim.
Maybe it could help a little bit to replace 'algorithm' by 'algo' and 'string' by 'str'.
IMHO, also shorter namespaces like 'boost::filesystem' have the problem of beeing too long to be used on every access. Long typenames like boost::filesystem::directory_iterator have a very high capability to make the code unreadable very quickly.
What's wrong with
namespace fs = boost::filesystem;
?
I would turn the question around and ask what's wrong with boost::fs (and when I see boost I think std). I've never understood the rationale behind long namespace names. Yes, I can alias filesystem to fs myself. But when all of your users alias filesystem to fs, and you find yourself doing the same in documentation, examples, tests, and in your own code, then perhaps it should have been named fs in the first place.
I do all sorts of things in non-header source files that I would not dare do in headers, and creating a name like "fs" is one of them :) Doug
Douglas Paul Gregor wrote:
On Wed, 18 Feb 2004, Peter Dimov wrote:
I would turn the question around and ask what's wrong with boost::fs (and when I see boost I think std). I've never understood the rationale behind long namespace names. Yes, I can alias filesystem to fs myself. But when all of your users alias filesystem to fs, and you find yourself doing the same in documentation, examples, tests, and in your own code, then perhaps it should have been named fs in the first place.
I do all sorts of things in non-header source files that I would not dare do in headers, and creating a name like "fs" is one of them :)
But the question is why (and the name is boost::fs). Claiming the identifier 'fs' in the boost namespace isn't more evil than claiming the identifier 'ref' or 'type' or 'bind'... or 'function', if you will.
On Wed, 18 Feb 2004, Peter Dimov wrote:
I would turn the question around and ask what's wrong with boost::fs (and when I see boost I think std). I've never understood the rationale behind long namespace names. Yes, I can alias filesystem to fs myself. But when all of your users alias filesystem to fs, and you find yourself doing the same in documentation, examples, tests, and in your own code, then perhaps it should have been named fs in the first place.
I do all sorts of things in non-header source files that I would not dare do in headers, and creating a name like "fs" is one of them :)
But the question is why (and the name is boost::fs). Claiming the identifier 'fs' in the boost namespace isn't more evil than claiming the identifier 'ref' or 'type' or 'bind'... or 'function', if you will.
I'm not going to defend "type", because I'm not thrilled that it's there. As for the others, only "ref" is an abbreviation, but we're knocking something that's huge ("reference_wrapper", 17 characters) and is often used several times in one line of code down to 3 characters. I think it's a fuzzy line in the sand, so all I really know is that I do like "ref" and don't like "fs" :) Doug
Douglas Paul Gregor wrote:
On Wed, 18 Feb 2004, Peter Dimov wrote:
But the question is why (and the name is boost::fs). Claiming the identifier 'fs' in the boost namespace isn't more evil than claiming the identifier 'ref' or 'type' or 'bind'... or 'function', if you will.
I'm not going to defend "type", because I'm not thrilled that it's there. As for the others, only "ref" is an abbreviation, but we're knocking something that's huge ("reference_wrapper", 17 characters) and is often used several times in one line of code down to 3 characters.
I think it's a fuzzy line in the sand, so all I really know is that I do like "ref" and don't like "fs" :)
Yes, is seems that it comes down to personal preference. Dave likes to say filesystem, and you don't like fs. Out of curiosity, do you like 'std'? The reason I prefer short namespace names (and I'm very glad that the committee decided to place the library in 'std' and not 'standard' or 'standard_library') is because I want to keep my identifiers fully qualified, if possible. However I apparently lack the mental discipline required to repeatedly type boost::filesystem::directory_iterator, std::string::size_type, std::string::npos, or std::vector<X>::size_type (much less like it :-) ). I believe that there is a (subjective) threshold that shouldn't be crossed, or the programmer just "goes unqualified". Now, it's well known that many programmers don't tolerate namespaces at all. Others, apparently, are content with longer namespace names if this aids clarity. But I somewhat suspect that the majority are like me, they'll keep using qualified names until the library offers them an excuse to cut corners. So I'd rather not give them that excuse. Just my opinion, of course. :-)
On Wed, 18 Feb 2004, Peter Dimov wrote:
Douglas Paul Gregor wrote:
On Wed, 18 Feb 2004, Peter Dimov wrote:
But the question is why (and the name is boost::fs). Claiming the identifier 'fs' in the boost namespace isn't more evil than claiming the identifier 'ref' or 'type' or 'bind'... or 'function', if you will.
I'm not going to defend "type", because I'm not thrilled that it's there. As for the others, only "ref" is an abbreviation, but we're knocking something that's huge ("reference_wrapper", 17 characters) and is often used several times in one line of code down to 3 characters.
I think it's a fuzzy line in the sand, so all I really know is that I do like "ref" and don't like "fs" :)
Yes, is seems that it comes down to personal preference. Dave likes to say filesystem, and you don't like fs. Out of curiosity, do you like 'std'?
Yes, actually. Part of my weighting scheme has to do with how often I need to type it. With filesystem, for instance, I either use it very sparingly (and don't mind the typing), or I'm using it like mad and will go with an alias no matter what. With "std", I need it all the bloody time for everything, so it better be short. (Kind of like "ls" or "cd").
I believe that there is a (subjective) threshold that shouldn't be crossed, or the programmer just "goes unqualified". Now, it's well known that many programmers don't tolerate namespaces at all. Others, apparently, are content with longer namespace names if this aids clarity. But I somewhat suspect that the majority are like me, they'll keep using qualified names until the library offers them an excuse to cut corners. So I'd rather not give them that excuse.
I'm not against going unqualified in reasonably safe places, so it doesn't bother me quite as much. <stands up> My name is Doug Gregor, and I use using directives. <sits back down> I suspect we'll be arguing this for every longish name and shortish abbreviation that goes into Boost for a good, long time :) Doug
Douglas Paul Gregor <gregod@cs.rpi.edu> writes:
On Wed, 18 Feb 2004, Peter Dimov wrote:
Douglas Paul Gregor wrote:
On Wed, 18 Feb 2004, Peter Dimov wrote:
But the question is why (and the name is boost::fs). Claiming the identifier 'fs' in the boost namespace isn't more evil than claiming the identifier 'ref' or 'type' or 'bind'... or 'function', if you will.
I'm not going to defend "type", because I'm not thrilled that it's there. As for the others, only "ref" is an abbreviation, but we're knocking something that's huge ("reference_wrapper", 17 characters) and is often used several times in one line of code down to 3 characters.
I think it's a fuzzy line in the sand, so all I really know is that I do like "ref" and don't like "fs" :)
Yes, is seems that it comes down to personal preference. Dave likes to say filesystem, and you don't like fs. Out of curiosity, do you like 'std'?
Yes, actually. Part of my weighting scheme has to do with how often I need to type it. With filesystem, for instance, I either use it very sparingly (and don't mind the typing), or I'm using it like mad and will go with an alias no matter what. With "std", I need it all the bloody time for everything, so it better be short. (Kind of like "ls" or "cd").
That's basically my philosophy. Couple that with a belief that the use of indcphrble abbrevs should be a conscious choice on each programmer's part, and not forced upon them by cruel or lazy library authors <wink>, and I think you can understand why I don't like boost::algo or boost::fs by default. If I could think of a better alternative I might say the same about boost::mpl. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Douglas Paul Gregor <gregod@cs.rpi.edu> writes:
Yes, actually. Part of my weighting scheme has to do with how often I need to type it. With filesystem, for instance, I either use it very sparingly (and don't mind the typing), or I'm using it like mad and will go with an alias no matter what. With "std", I need it all the bloody time for everything, so it better be short. (Kind of like "ls" or "cd").
That's basically my philosophy. Couple that with a belief that the use of indcphrble abbrevs should be a conscious choice on each programmer's part, and not forced upon them by cruel or lazy library authors <wink>, and I think you can understand why I don't like boost::algo or boost::fs by default. If I could think of a better alternative I might say the same about boost::mpl.
I hate 'algo' too. :-) But you are missing the point. Abbreviations are only introduced as namespace (module, unit) names. A program typically uses hundreds, if not thousands, of identifiers, but the number of namespaces/modules/units is usually less than, say, 20. Furthermore, a namespace name is rarely used on its own; it only provides context to a non-abbreviated identifier. And if a long namespace name is using-directive-d away, it's arguably worse to have no context than a two-or-three-letter abbreviated, but well known, context. I even suspect that if you conduct a proper scientific experiment to compare the readability of boost::filesystem::directory_iterator or boost::regex_match against boost::fs::directory_iterator or boost::rx::match, the results may not support your "long names are obviously more readable" viewpoint. But that's another story. Cognitive sciences are probably off-topic for Boost. :-)
David A wrote:
Yes, actually. Part of my weighting scheme has to do with how often I need to type it. With filesystem, for instance, I either use it very sparingly (and don't mind the typing), or I'm using it like mad and will go with an alias no matter what. With "std", I need it all the bloody time for everything, so it better be short. (Kind of like "ls" or "cd").
That's basically my philosophy. Couple that with a belief that the use of indcphrble abbrevs should be a conscious choice on each programmer's part, and not forced upon them by cruel or lazy library authors <wink>, and I think you can understand why I don't like boost::algo or boost::fs by default. If I could think of a better alternative I might say the same about boost::mpl.
Strange coming from a man who I guess spends a large portion of his day in Unix land. Maybe I should start including the following lines in my .bash_profile: alias change_current_directory="cd" alias list_directory="ls" ;-) /David
"David Bergman" <davidb@home.se> writes:
David A wrote:
Yes, actually. Part of my weighting scheme has to do with how often I need to type it. With filesystem, for instance, I either use it very sparingly (and don't mind the typing), or I'm using it like mad and will go with an alias no matter what. With "std", I need it all the bloody time for everything, so it better be short. (Kind of like "ls" or "cd").
That's basically my philosophy. Couple that with a belief that the use of indcphrble abbrevs should be a conscious choice on each programmer's part, and not forced upon them by cruel or lazy library authors <wink>, and I think you can understand why I don't like boost::algo or boost::fs by default. If I could think of a better alternative I might say the same about boost::mpl.
Strange coming from a man who I guess spends a large portion of his day in Unix land.
Bad guess ;^)
Maybe I should start including the following lines in my .bash_profile:
alias change_current_directory="cd" alias list_directory="ls"
Shell commands are generally written once and thrown away. Code needs to be read many more times than it's written. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David A wrote:
Strange coming from a man who I guess spends a large portion of his day in Unix land.
Bad guess ;^)
Maybe I should start including the following lines in my .bash_profile:
alias change_current_directory="cd" alias list_directory="ls"
Shell commands are generally written once and thrown away. Code needs to be read many more times than it's written.
Totally agree, that is why I prefer using fully qualified identifiers. That combined with my laziness and not-wide-enough screen lead me to prefer short namespace names. Short as in "few letters but still very clear as to semantics." Like "fs", but maybe not like "mpl"... I will leave it at this, since I am deviating from Boost right now. /David
David Abrahams wrote:
Douglas Paul Gregor <gregod@cs.rpi.edu> writes:
Yes, actually. Part of my weighting scheme has to do with how often I need to type it. With filesystem, for instance, I either use it very sparingly (and don't mind the typing), or I'm using it like mad and will go with an alias no matter what. With "std", I need it all the bloody time for everything, so it better be short. (Kind of like "ls" or "cd").
That's basically my philosophy. Couple that with a belief that the use of indcphrble abbrevs should be a conscious choice on each programmer's part, and not forced upon them by cruel or lazy library authors <wink>, and I think you can understand why I don't like boost::algo or boost::fs by default. If I could think of a better alternative I might say the same about boost::mpl.
We can (re-)consider 'boost::meta': meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ... Doesn't look bad at all, actually. -- Aleksey Gurtovoy MetaCommunications Engineering
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character. -- Daniel Wallin
"Daniel Wallin" <dalwan01@student.umu.se> wrote in message news:40378F47.4090105@student.umu.se...
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
I like "meta".. If you're bothered by the extra character, how about just "mp"? After all, if it's part of boost, of course it must be a "library". On second though, it must involve "programming", too, so why not just "m"? Jonathan
Jonathan Turkanis wrote:
"Daniel Wallin" <dalwan01@student.umu.se> wrote in message news:40378F47.4090105@student.umu.se...
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
I like "meta"..
If you're bothered by the extra character, how about just "mp"? After all, if it's part of boost, of course it must be a "library". On second though, it must involve "programming", too, so why not just "m"?
Because it's too generic. mpl is sufficiently unique and restricts the library domain enough. -- Daniel Wallin
"Daniel Wallin" <dalwan01@student.umu.se> wrote:]
Jonathan Turkanis wrote:
If you're bothered by the extra character, how about just "mp"? After all, if it's part of boost, of course it must be a "library". On second though, it must involve "programming", too, so why not just "m"?
Because it's too generic. mpl is sufficiently unique and restricts the library domain enough.
I forgot a smiley face. Too much typing ;- Jonathan
Daniel wrote:
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
You are kidding, right? One extra character... :-) I do not like "meta," because it is actually more general (I almost said "more generic"...) then "meta programs using templates for dealing with type manipulation (and simple arithmetics,) executed at compile-time" which is what MPL is all about, and for some reason "meta programming" have become synonymous with that kind of manipulation in the modern C++ world. "Meta," on the other hand, can (still) denote "logic or data reasoning about or representing logic or structures," such as in "meta data" for repositories... In my opinion, the most correct, albeit lengthy, notation would be "compile_time_type_programing"... /David
David Bergman wrote:
Daniel wrote:
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
You are kidding, right? One extra character... :-)
No I'm not kidding. One more extra character means a much bigger part of the identifiers will be occupied by the namespace name. It makes my code harder to write and more importantly harder to read. It is worse in the case of mpl, since you almost always have to qualify the names. -- Daniel Wallin
Daniel wrote:
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
You are kidding, right? One extra character... :-)
No I'm not kidding. One more extra character means a much bigger part of the identifiers will be occupied by the namespace name. It makes my code harder to write and more importantly harder to read. It is worse in the case of mpl, since you almost always have to qualify the names.
Ok, sorry. I did not know how much grief one extra character can cause. ;-) Ha're bra, David
At Saturday 2004-02-21 11:06, you wrote:
David Bergman wrote:
Daniel wrote:
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
You are kidding, right? One extra character... :-)
No I'm not kidding. One more extra character means a much bigger part of the identifiers will be occupied by the namespace name. It makes my code harder to write and more importantly harder to read. It is worse in the case of mpl, since you almost always have to qualify the names.
a ghostly voice comes out of the north "using....."
-- Daniel Wallin _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Daniel Wallin <dalwan01@student.umu.se> writes:
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually. I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
Sheesh! -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Daniel Wallin <dalwan01@student.umu.se> writes:
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually. I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
Sheesh!
:-) mpl > meta not because of the extra character, but because mpl is specific/unique and meta is generic.
David Abrahams wrote:
Daniel Wallin <dalwan01@student.umu.se> writes:
Douglas Gregor wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
Sheesh!
I should have probably said that what would bother me isn't really the typing, but rather that my screenspace would be occupied by characters that convey no or very little additional information. I can't imagine anyone's life getting any easier by calling it "meta" instead of "mpl". -- Daniel Wallin
Daniel wrote:
FWIW, I'm not. I type it often enough to be bothered by the completely unnecessary extra character.
Sheesh!
I should have probably said that what would bother me isn't really the typing, but rather that my screenspace would be occupied by characters that convey no or very little additional information. I can't imagine anyone's life getting any easier by calling it "meta" instead of "mpl".
Well, my life would have been easier the first few times I encountered MPL. Had no clue what that was refering to, whereas I would have a clue had it been "meta"... So, I guess the bottom-line is that "boost::algorithm:string" would not be your first choice? ;-) /David
At Saturday 2004-02-21 08:51, you wrote:
On Saturday 21 February 2004 04:59 am, Aleksey Gurtovoy wrote:
We can (re-)consider 'boost::meta':
meta::if_<...> meta::find<> meta::vector<> meta::set<> meta::map<> ...
Doesn't look bad at all, actually.
I'm a big fan of using "meta" instead of "mpl".
ditto
Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
I stand by Peter Dimov, in (co-dependent) terms of 1. my use of fully qualified identifiers as often as possible 2. not wanting to be "forced" to alias, via "using fs = ...", although it is yet another nice trick of C++ seniority that we can show off to the junior guys ;-) 3. thinking that short qualifiers are good 4. thinking that "fs" is common enough for "filesystem" (ntfs, nfs, afs...) I also think all the algorithms should be exposed in the namespace "boost:"; either directly placed in that namespace or included by a "using ..." in the top header. The algorithms should definitely not be placed any lower than "boost::algorithm" (which should be renamed "boost::algo".) /David
"David Bergman" <davidb@home.se> wrote in message news:200402202123.i1KLNO514936@heart-of-gold.osl.iu.edu...
[...] The algorithms should definitely not be placed any lower than "boost::algorithm" (which should be renamed "boost::algo".)
Or, for Daniel Wallin's "three-char rule", we should call it "boost::alg". ;) Hopefully it won't get confused with "algebra" or "algae". Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004
At 03:28 PM 2/18/2004, Peter Dimov wrote:
I think it's a fuzzy line in the sand, so all I really know is that I do like "ref" and don't like "fs" :)
Yes, is seems that it comes down to personal preference. Dave likes to say filesystem, and you don't like fs...
I never liked either. "filesystem" is too long and sounds affected. "fs" is too short and non-specific. Those names just escaped because nothing better surfaced. Maybe if the LWG likes the library enough to standardize it we can come up with a better name. --Beman
On Mon, 23 Feb 2004 14:44:29 -0500, Beman Dawes wrote
At 03:28 PM 2/18/2004, Peter Dimov wrote:
I think it's a fuzzy line in the sand, so all I really know is that I do >> like "ref" and don't like "fs" :) > >Yes, is seems that it comes down to personal preference. Dave likes to say >filesystem, and you don't like fs...
I never liked either. "filesystem" is too long and sounds affected. "fs" is too short and non-specific. Those names just escaped because nothing better surfaced.
FWIW (irony here), most of the perl modules dealing with files use either File or Filesys. My guess is that it is impossible to make everyone happy here but personally I'm fine with filesystem. But I'm with Dave on prefering spelled out names in general. Abbreviation is a hard habit to break, but overall it just obscures code IME (that's in my experience ;-) Jeff
Jeff Garland wrote:
But I'm with Dave on prefering spelled out names in general.
The question is not what we prefer, but what is best for the C++ community. Millions of C++ programmers will be stuck with the standard we are writing for years to come. Personal preferences should not interfere with our ability to do what is best for them.
Beman Dawes <bdawes@acm.org> writes:
At 03:28 PM 2/18/2004, Peter Dimov wrote:
I think it's a fuzzy line in the sand, so all I really know is that I do like "ref" and don't like "fs" :)
Yes, is seems that it comes down to personal preference. Dave likes to say filesystem, and you don't like fs...
I never liked either. "filesystem" is too long and sounds affected. "fs" is too short and non-specific. Those names just escaped because nothing better surfaced.
Maybe if the LWG likes the library enough to standardize it we can come up with a better name.
Just a thought: "files" is about the right length, and says about the right thing. If you're not abbrev-adverse it could even stand for "filesystem". -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 03:56 AM 2/24/2004, David Abrahams wrote:
Beman Dawes <bdawes@acm.org> writes:
filesystem, and you don't like fs...
I never liked either. "filesystem" is too long and sounds affected. "fs" is too short and non-specific. Those names just escaped because nothing better surfaced.
Maybe if the LWG likes the library enough to standardize it we can come up with a better name.
Just a thought: "files" is about the right length, and says about the right thing. If you're not abbrev-adverse it could even stand for "filesystem".
Yes, "files" would work. I'll add it to the lists of candidates. --Beman
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes | Sent: 23 February 2004 19:44 | To: Boost mailing list | Subject: Re: [boost] Re: algorithms namespace | Maybe if the LWG likes the library enough to standardize it | we can come up with a better name. | | --Beman FWIW I like files meta algorithm functional Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
"Peter Dimov" <pdimov@mmltd.net> writes:
I would turn the question around and ask what's wrong with boost::fs (and when I see boost I think std). I've never understood the rationale behind long namespace names. Yes, I can alias filesystem to fs myself. But when all of your users alias filesystem to fs, and you find yourself doing the same in documentation, examples, tests, and in your own code, then perhaps it should have been named fs in the first place.
I was very happy typing boost::filesystem::iterator when I used it, and I think it only benefitted the clarity of my code. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
I would turn the question around and ask what's wrong with boost::fs (and when I see boost I think std). I've never understood the rationale behind long namespace names. Yes, I can alias filesystem to fs myself. But when all of your users alias filesystem to fs, and you find yourself doing the same in documentation, examples, tests, and in your own code, then perhaps it should have been named fs in the first place.
I was very happy typing boost::filesystem::iterator when I used it, and I think it only benefitted the clarity of my code.
But long namespace names encourage the use of abbreviations and many abbreviations means many DIFFERENT abbreviations. This is surly not beneficial for code readability! What would be wrong about having both _as standard_? namespace boost::filesystem { // ... } namespace boost::fs = boost::filesystem; This would have some big advantages: -) The user can choice between using the long or the short name (abbreviation) -) boost::fs clearly shows the origin of the type (boost). -) The abbreviaton is standardized and can so be used consistently in both the documentation and the code. Anyway, I don't agree to the argument of bringing some danger with short names in header files; boost::ref and boost::fs really don't make the big difference! Stefan
What would be wrong about having both _as standard_?
namespace boost::filesystem { // ... }
namespace boost::fs = boost::filesystem;
This would have some big advantages:
-) The user can choice between using the long or the short name (abbreviation)
-) boost::fs clearly shows the origin of the type (boost).
-) The abbreviaton is standardized and can so be used consistently in both the documentation and the code.
I think this last point is important. I'm okay with writing std::cout or std::for_each. It only adds 5 chars which isn't enough to disturb me. If the standard library had instead been namespace "standard" I'd probably always write "using namespace standard" at the top of all my programs. I don't like use of renaming namespaces in client code - it is something that a programmer has to hunt through code (possibly in another header file) to found out what it refers to. But having the library define the short form as proposed above makes sense. Darren
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Darren Cook | Sent: 19 February 2004 23:49 | To: Boost mailing list | Subject: Re: [boost] Re: algorithms namespace | | I'm okay with writing std::cout or std::for_each. It only | adds 5 chars which | isn't enough to disturb me. If the standard library had instead been | namespace "standard" I'd probably always write "using | namespace standard" at | the top of all my programs. What is your objection to writing #include <iostream> using std::cout; using std::for_each; // etc either locally to a block or procedure, or with wider scope? IMHO this also helpfully documents for the user where things are coming from, avoids the clutter from full file specifications, and avoids the pitfalls with name clashes and selection surprises that 'using namespace std & boost etc' creates. If things move from boost:: to std::, say, I'd prefer to see the changes documented as explicitly as possible. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
participants (17)
-
Aleksey Gurtovoy -
Beman Dawes -
Daniel Wallin -
Darren Cook -
David Abrahams -
David B. Held -
David Bergman -
Douglas Gregor -
Douglas Paul Gregor
-
Jeff Garland -
Jonathan Turkanis -
Paul A Bristow -
Pavel Vozenilek -
Pavol Droba -
Peter Dimov -
Stefan Slapeta -
Victor A. Wagner Jr.