Re: [boost] Re: algorithms namespace

From: Pavol Droba (droba_at_[hidden])
Date: 2004-02-22 13:57:30

On Sat, Feb 21, 2004 at 09:28:54PM +0200, Peter Dimov wrote:
> Dave Gomboc wrote:
> >
> > Besides which, "fs" is difficult for an English-as-a-second-language
> > speaker to look up in the dictionary.  I have the impression that some
> > simply don't care about that because English is _their_ first language
> > -- an unfortunate attitude.
> 
> Well. It's actually the opposite. Because English is (presumably) your first
> language, you prefer the non-abbreviated "filesystem" over "fs". From the
> perspective of someone who doesn't "think in English", the two have pretty
> much the same inherent value, i.e. they are arbitrary identifiers. A mental
> mapping translates these identifiers into the entities they represent. Since
> the extra letters in the longer identifier do not add any semantic value to
> non-English speakers, they are merely clutter and do not contribute to
> readability.
> 
> Your observation that "stdio" is a _word_ in non-English programmer
> cultures, and not an abbreviation of "standard input/output", is very much
> in line with the above.
> 

I'm a non-English programmer. All I can say is that I agree with the above.
Altough I understand that "stdio" is and abrevation of "standard input/output",
for me it is and it always will be just stdio. I don't need to find a 
natural-language meaning for that, because the I'm using it only in relation
to computers.

Similary it is with the filesystem. It is only a term identifying something
what have to do with organization of files. Without propert background in
computers, it has no natural meaning at all (or very unrelated to the real purpose).
Actualy for me, a "file" is most of the time a file on the disk. I learned
the meaining of th real-world file quite a long time after I learned a lot about computer
files. And I never felt, that I need this information to understand what
does computer file mean.

What I'm trying to say is that, it does not matter for me if an entity has a very nice
sounding english name or if it is just an abrevation for something. The term
will denote only that paricular entity and nothing else. I will not try to
assign some natural association with the real world. Such an association is 
many times more confusing then helpful.

Now about the long namespaces. I would always prefer shorter, but still meaningful
abrevation to a loooooong name. I'm always have to use namespace alias for filesystem.
Simply, because to code is much less readable when I would have to use
filesystem:: all the time. In the code, more important part is after "filesystem::" 
(a method name), and long prefix is just a distraction when reading the code. 

If somebody is reading a code, she/he woudld have to look into documentation anyway,
to understand what is hidden under namespace filesystem::. It is very same
for abrevation "fs". How can anybody try to understand the code without knowing
what's behind the calls? I don't think, that code:

the_great_library::sublibrary::specific_part::get_line(
    the_second_great_library::common_stuf::line(1) );

is any more readable then

gl::get_line( sl::line(1) );

First example hides the important parts of the code behind the long prefixes,
making the code much less readable.

In my code, I try to never use more then one level of namespaces. I don't like global
"using namespace" directives, so I'm using aliases for deeper namespace.
For example:
namespace lambda=boost::lambda;
namespace fs=boost::filesystem;

That's my 0.5 SKK

Regards,

Pavol