RE: [boost] Re: algorithms namespace
I'm siding with Dave A and the longer names. You can always shorten it in your code with an alias. For me it's a matter of future expansion, and maintenance, we have boost::bind, and boost::lambda::bind, and perhaps soon boost:fcpp::lambda which is the namespace which the function? If we use apprev. 4 everythg, thn, we lose contx. boost::fs =? "FileSystem", "FastSort", "FirstSearch", "FloatingSymbols".... yes these are a bit contrived but you can usually use "using namespace", or a namespace alias safely within a function scope. Then when you leave the company the next poor maintainer of your code has a chance. Also a global search is easier if the letters to be searched for are more or less a unique set. Yours, -Gary- -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Monday, February 23, 2004 11:44 AM To: Boost mailing list Subject: Re: [boost] Re: algorithms namespace 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Powell, Gary wrote:
I'm siding with Dave A and the longer names.
You are missing most of the points, though. ;-)
You can always shorten it in your code with an alias.
This is precisely what makes it dangerous. Design mistakes that have a trivial workaround are the worst, because you will never get the feedback that will set you on the right path. Everyone just patches around it locally.
For me it's a matter of future expansion, and maintenance, we have boost::bind, and boost::lambda::bind, and perhaps soon boost:fcpp::lambda which is the namespace which the function? If we use apprev. 4 everythg, thn, we lose contx.
No we do not. The abbrv anlgy is flwd. It's more like English::this English::kind English::of English::writing versus en::this en::alternative en::style.
boost::fs =? "FileSystem", "FastSort", "FirstSearch", "FloatingSymbols".... yes these are a bit contrived but you can usually use "using namespace", or a namespace alias safely within a function scope. Then when you leave the company the next poor maintainer of your code has a chance.
Also a global search is easier if the letters to be searched for are more or less a unique set.
Of course it isn't. Your global search for 'filesystem' will only find using directives and namespace alias directives. A global search for 'fs' will stand a better chance to point you to the lines that actually use something from 'fs'.
Peter wrote:
Powell, Gary wrote:
I'm siding with Dave A and the longer names.
You are missing most of the points, though. ;-)
You can always shorten it in your code with an alias.
This is precisely what makes it dangerous. Design mistakes that have a trivial workaround are the worst, because you will never get the feedback that will set you on the right path. Everyone just patches around it locally.
Exactly. What do certain people think is so hard with "fs"? *If* someone would not have an intuitive sense of what "fs" might mean, it should be a fairly short education... Regarding non-native speakers, I thought we were all English speaking when it came to software engineering? I do not understand why, and how, the nativeness of this tongue would affect the comprehensibility of "fs." I think we all agree on having telling names. I think we do disagree on whether "fs" (and similar abridged variants) are indicative as to their meaning. And, some people are dogmatically against abridged lexemes. I assume some of those people live in the United States of America, whereas I live in the U.S. Regarding the ease of searching for explicit (read "long") namespaces in source files, Peter succinctly pointed out:
Of course it isn't. Your global search for 'filesystem' will only find using directives and namespace alias directives. A global search for 'fs' will stand a better chance to point you to the lines that actually use something from 'fs'.
Hear! Hear! /David
David Bergman wrote:
Peter wrote:
Powell, Gary wrote:
I'm siding with Dave A and the longer names.
You are missing most of the points, though. ;-)
You can always shorten it in your code with an alias.
This is precisely what makes it dangerous. Design mistakes that have a trivial workaround are the worst, because you will never get the feedback that will set you on the right path. Everyone just patches around it locally.
Exactly. What do certain people think is so hard with "fs"? *If* someone would not have an intuitive sense of what "fs" might mean, it should be a fairly short education...
Regarding non-native speakers, I thought we were all English speaking when it came to software engineering? I do not understand why, and how, the nativeness of this tongue would affect the comprehensibility of "fs."
I think we all agree on having telling names. I think we do disagree on whether "fs" (and similar abridged variants) are indicative as to their meaning. And, some people are dogmatically against abridged lexemes. I assume some of those people live in the United States of America, whereas I live in the U.S.
Actually if namespace identifiers in C++ could have a dot ( '.' ) in them and if it was normally acceptable to use all uppercase letters in namespace identifiers ( usually reserved for macros ), I would be more likely to agree with you. Now imagine if 'U.S.' was 'us', don't you think such a short abbreviation could cause problems in normal use, and the United States would be more understandable ?
Edward wrote:
I think we all agree on having telling names. I think we do disagree on whether "fs" (and similar abridged variants) are indicative as to their meaning. And, some people are dogmatically against abridged lexemes. I assume some of those people live in the United States of America, whereas I live in the U.S.
Actually if namespace identifiers in C++ could have a dot ( '.' ) in them and if it was normally acceptable to use all uppercase letters in namespace identifiers ( usually reserved for macros ), I would be more likely to agree with you. Now imagine if 'U.S.' was 'us', don't you think such a short abbreviation could cause problems in normal use, and the United States would be more understandable ?
No, I do not think so. You must remember the context. If the abbreviation "us" or "US" was used in a political or geographical setting, it would be quite intuitive. Likewise would "fs" in the context of sowftare solutions. Forms like "algo", "dir", "jmp" and "enum" are quite intuitive for a software engineer. Additionally, I am glad the U.S. actually *is* "us" as far as localization issues are concerned. Noone misunderstands the lexeme "us-EN" in our field. /David
"Peter Dimov" <pdimov@mmltd.net> writes:
Powell, Gary wrote:
For me it's a matter of future expansion, and maintenance, we have boost::bind, and boost::lambda::bind, and perhaps soon boost:fcpp::lambda which is the namespace which the function? If we use apprev. 4 everythg, thn, we lose contx.
No we do not. The abbrv anlgy is flwd. It's more like English::this English::kind English::of English::writing versus en::this en::alternative en::style.
Believe it or not the latter caused me a bigger mental hiccup. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
"Peter Dimov" <pdimov@mmltd.net> writes:
Powell, Gary wrote:
For me it's a matter of future expansion, and maintenance, we have boost::bind, and boost::lambda::bind, and perhaps soon boost:fcpp::lambda which is the namespace which the function? If we use apprev. 4 everythg, thn, we lose contx.
No we do not. The abbrv anlgy is flwd. It's more like English::this English::kind English::of English::writing versus en::this en::alternative en::style.
Believe it or not the latter caused me a bigger mental hiccup.
They both hindered reading the text. Upon seeing "English::this," I had to consider whether "::" was a typo for ": " or a namespace qualification on "this." Since the former was more likely than the latter, even given the context, I was expecting the former. When I saw "English::kind," it became apparent that I needed to *ignore* "English::" and just read the unqualified words. Thus, when I got to "en::this," it was only a momentary hiccup to note that "en::" was equivalent to "English::" and continue reading by *ignoring* the "en::" part. I emphasized the word "ignore" in the foregoing because that's what I do when reading qualified code. I skip over the line noise to find the important information. Only when things go awry do I pay attention to the qualifications to get the extra information. That is why I prefer shorter namespace names: they reduce the line noise. An abbreviation should be as short as possible, but no shorter, to turn a phrase. My point is that making a namespace name too short increases the chance of it being incomprehensible to many and suggestive of other long names. The case was already made for "fs" possibly meaning things like "File System," "Financial Services," "Fabulous Sockets," or whatever. Note, however, that in this case, "fs" is well established as an abbreviation for "filesystem" and could easily pass the too short filter. (Those other libraries would need longer namespaces.) Thus, choosing a good namespace name means to keep it as short as possible without losing uniqueness and clarity, considering its frequency of use. The more often a namespace name will be used in real code, the shorter it should be. "algo" is a common abbreviation, in my experience for "algorithm" and is much easier to spell (not to mention type)! That makes it a good alternative, but "fs" is a good abbreviation for "filesystem," but "file" or "files" would work just as well. Each library has to be handled case by case. When reviewing a library, one can comment on the namespace name as well as anything else. That could even be made a specific point to consider during a review. That way, you get various opinions and suggestions and the library author can make the final determination. They won't all be entirely consistent, since each library author gets to choose, but hopefully a groundswell of support for a namespace name contrary to the author's preference will sway his/her opinion. If Boost chooses to change a namespace name, the old name can be retained, via namespace alias, for a few versions, marking it deprecated upon the introduction of the new name. That makes the transition to a "better" name easier. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
If Boost chooses to change a namespace name, the old name can be retained, via namespace alias, for a few versions, marking it deprecated upon the introduction of the new name. That makes the transition to a "better" name easier.
It's not that simple; we'll break specializations if we ever do that. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 2/26/04 5:57 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
Rob Stewart <stewart@sig.com> writes:
If Boost chooses to change a namespace name, the old name can be retained, via namespace alias, for a few versions, marking it deprecated upon the introduction of the new name. That makes the transition to a "better" name easier.
It's not that simple; we'll break specializations if we ever do that.
How? (I'm assuming that code within Boost will change to use the new name.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
On 2/26/04 5:57 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
Rob Stewart <stewart@sig.com> writes:
If Boost chooses to change a namespace name, the old name can be retained, via namespace alias, for a few versions, marking it deprecated upon the introduction of the new name. That makes the transition to a "better" name easier.
It's not that simple; we'll break specializations if we ever do that.
How? (I'm assuming that code within Boost will change to use the new name.)
Users are allowed to write specializations; they must write them within the same namespace as the primary template. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Mon, 23 Feb 2004 18:21:19 -0800, Powell, Gary wrote:
I'm siding with Dave A and the longer names. You can always shorten it in your code with an alias.
And, you can always lengthen a short name with an alias. In fact, you might end up with something more usable: namespace filesystem = boost::fs; Not that I actually like "fs" very much, but the argument about what can be aliased to what seems rather specious to me as a justification for picking one form over the other. At the end of the day, it's just a name - the fact that people who use boost::spirit don't think it is a C++ extension for communicating with the dead suggests to me that the name quickly becomes irrelevant to anybody using it. The key thing is to make sure that people who want to use a library facility can find it - this is the one place where a long name *might* help, but generally the docs do it better. "fcpp" falls into the same category as "spirit". It is a "product" name, not a functional description (no pun intended) - algorithm and filesystem fall into the latter category. So what? I dunno. I'm siding with nobody - I don't like abbreviations, but I also don't like enormously long fully qualified names. I sort of like David's "files", but it doesn't quite scan correctly to my eye (probably because it's a plural). All this does is reinforce my view that naming things is frequently the hardest thing to do right :-) Sorry for rambling, phil -- change name before "@" to "phil" for email
During the last years, i have been working with images and i had to have a library for image processing. Besides other libraries that i have used, i created some classes/functions of my own that helped us a 'glue' and allowed me to program in my (very simple - and i hope clear) programming style. Allthough i cannot provide the boost library with a full image-processing library (with image loading-saving facilities), i would like to submit a library containing source code that includes a templated image class. The source code is very simple and depends on nothing but the allocating function ('new' is used, but another could be used, easilly). (an appropriate header would be image/image.h"): This class takes into concideration the facts that: 1) most platforms use an alignment for the image lines. the 'align' template parameter takes care of that. Possibly, the result of lineSize should be stored as a variable inside the class. This is the reason char* is used instead of the actual pixel type, in allocation. I know that this limits the acceptable pixel types to simple types:( 2) accessing the image data is done in a per-line basis. (The operator [] returns a pointer to a line of the image.) 3) Other image libraries may exist and be used with this library. It is possible to initialize the class with external data and later 'unlockData', so that it is not deleted. The use of the class is very simple: One writes a[y][x], where a is a TImage<...> instance to access pixel at (x, y). Issues: 1) The boost naming conventions are not followed, but this can be done easilly... 2) Not using iterators: A set of begin(), end() e.t.c iterators, in the manner of vector can be used here, for the lines of the image, or even the pixels in it. Definitions of pixel types and converting functions are included. I would like to include also: A toolkit for 2D graphics, that works well with the above class allowing the user to 'draw' on top of this image. This consists mainly of a 'graphics' class. However, to do that, a set of definitions must allready be there for basic 2d geometry, such as points, polygons, e.t.c. About a million people must have defined structs/classes/functions for that purpose. I have some code that can be used as a basis for points/polygons e.t.c., but if someone else allready has something ready for this purpose, i am willing to make MY source code compatible to his/her. If the people of boost are interested in any of the above ideas, i will commit a (more boost-compliant) version of this library. Andreou Ioannis Unversity of Piraeus Greece P.S. A section of the TImage (to be image::image) class follows: template<class PixT, int align> class TImage{ char* _pixels; int w, h; public: typedef PixT pixel_type; inline TImage(int w1, int h1){ w=w1; h=h1; int lSize=lineSize(); _pixels=new char[lSize*h]; } inline TImage(){ w=0; h=0; _pixels=0; } inline TImage(int w1, int h1, char* p){ //must unlock later!!! w=w1; h=h1; _pixels=p; } inline ~TImage(){ if(_pixels) delete [] _pixels; } inline int pixelSize()const{ return sizeof(pixel_type); } inline int alignment()const{ return align; } inline int width()const{ return w; } inline int height()const{ return h; } inline int size()const{ //in pixels return w*h; } inline void setSize(int w1, int h1){ if(w==w1 && h==h1) return; if(_pixels) delete _pixels; w=w1; h=h1; _pixels=new char[totalSize()]; } inline void setData(int width, int height, char* p){ if(_pixels) delete _pixels; w=width; h=height; _pixels=p; } inline void unlockData(){ //let data go, w/o delete w=0; h=0; _pixels=0; } ... ... inline pixel_type* operator[](int i)const{ return (pixel_type*)( _pixels+(i*lineSize()) ); } .... }; ... template<typename DstIm, typename SrcIm, typename Func> void im_convert(DstIm& dst, SrcIm& src, Func& func){ int w=src.width(); int h=src.height(); dst.setSize(w, h); for(int i=0; i<h; i++){ for(int j=0; j<w; j++){ func((dst)[i][j], (src)[i][j]); } } } ...
Andreou Giannis <gandreou@unipi.gr> writes:
During the last years, i have been working with images and i had to have a library for image processing.
Did you look at Ullrich Koethe's VIGRA library? -- Dave Abrahams Boost Consulting www.boost-consulting.com
No, i didn't. David Abrahams wrote:
Andreou Giannis <gandreou@unipi.gr> writes:
During the last years, i have been working with images and i had to have a library for image processing.
Did you look at Ullrich Koethe's VIGRA library?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Phil Richards <news@derived-software.ltd.uk> writes:
I'm siding with nobody - I don't like abbreviations, but I also don't like enormously long fully qualified names. I sort of like David's "files", but it doesn't quite scan correctly to my eye (probably because it's a plural).
It's not perfect for me either. It just happens to be consistent with prior art. See boost::tuples. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (9)
-
Andreou Giannis -
Daryle Walker -
David Abrahams -
David Bergman -
Edward Diener -
Peter Dimov -
Phil Richards -
Powell, Gary -
Rob Stewart