Re: ext/ names (was: re:[PATCH] HP/SGI extensions to...)

[Paolo Carlini <pcarlini at unitus dot it>]

Benjamin Kosnik wrote:

> > > How about ext/rb_tree.h, then?
> >
> > I don't particularly mind one way or another.
>
> I don't either. However, let's be consistent, and have all the
> user-include-able ext headers either have a suffix or not.

I'm just back home and this is definitely one of the replies to my message I
like most!

Also, I completely agree with Phil, as regards stl_tempbuf.h being included by
std_memory.h and therefore going to ext/memory*. On the other hand, honestly
ext/rb_tree* seems to me a little bit too narrow: in principle, each different
kind of tree would have an independent include file? But ok, ext/rb_tree* is ok
for me too.

Currently, every modern (not the backward, deprecated ones) header file meant to
be included by the user does *not* have any extension: indeed, when I started my
task, I found in the ext directory slist, hash_map, hash_set, rope. I think,
naively perhaps, that when you learn C++, you learn that C++ header files do not
have a .h extension. You learn that, even if you unfortunately don't have any
first hand information on the actual meetings of the standard commitee. As time
passes, you ends up finding such naming scheme much more elegant. This is of
course only my humble, personal, point of view.

Of course, things would be completely different if, from an "engineering" point
of view, as Nathan says (I'm an electronical engineer myself!) we accumulate
compelling evidence that extentionless header names are dangerous in some way...

Tomorrow I would like to try almost completing the "hard" work by moving
stl_tempbuf.h to ext/memory and struct rb_tree to ext/rb_tree, i.e. I would like
to keep using the current extensionless naming scheme. Then I will rescan all
the header files in search of other HP/SGI extensions unnoticed during my first
recognition.

... by the way: how do you rename files with CVS? ;-)

Cheers,
Paolo.