Re: Extensionless headers

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Sat, Jan 05, 2002 at 06:57:18AM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <pedwards@disaster.jaj.com> writes:
> 
> | On Fri, Jan 04, 2002 at 09:56:45PM +0000, Nathan Myers wrote:
> | > The committee's political hackery certainly didn't touch on why
> | > they are needed. (Anyway the discussion at the time assumed that
> | > the actual filenames would continue to be extended; the canonical
> | > comment was that "they are header names, not files; it's the
> | > implementation's job to provide a set of declarations when it sees
> | > include <foo>, and it's none of our business how".)
> | 
> | Here's a simple proposal to make everyone happy:
> | 
> | 1)  Leave the standard headers where they are (in std not bits), and
> |     rename them in place from foo to std_foo.h.  Essentially moving
> |     std_foo.h from bits to std, just spread out over a couple of days.
> | 
> | 2)  Change include/Makefile.am to that when the staging headers are
> |     created, they are done with standard names:
> | 
> |        include/foo  ->  ...../include/std/std_foo.h
> 
> 
> What type of problems is that supposed to solve? I've heard of syntax
> highlighting, that argument isn't one since .h files are interpreted
> as C header files, not C++ one.  Find? if all standard headers follow
> the same policy, that doesn't make any difference whether they are
> extensionless or not.  

I agree that Phil's suggestion doesn't help to solve the problems I'm 
worried about.  

The problem is the proliferation of extensionless names.  Can I count 
on anybody to keep up-to-date a complete list of all the sources and 
their types in conveniently machine-readable form?  The filename
extensions had done that for us, and for our tools, automatically.
 
> Since this list has seen unnecessary inflammatory rhetorics on that
> issue, I would like to see at least one compelling reason justifying
> those inflammatory rhetorics.

The long-standing written policy is to maintain filename extensions.  
It seems to me that the burden of proof should be upon those arguing 
to abandon this industry-wide organizational tool.

So far I have only seen vague remarks about "elegance" and 
"consistency".  Nobody has offered any examples of how those claimed 
qualities lead to any good practical consequence.  Nobody has offered 
any comprehensive substitute for the mechanism we have used.  All we 
get are idiosyncratic, incomplete workarounds for each problem as it 
is raised.

Think: why have the none of the Linux, XFree86, BSD, Apache, Perl,
Mozilla, Gnome, Emacs, Glibc -- or even Gcc -- projects abandoned 
these archaic, inelegant filename extensions?  Does anyone imagine 
any of them following our lead?

We already have a comprehensive solution, and we we need only avoid 
abandoning it.  It is all too easy for a big project like libstdc++ 
to turn into unmaintainable mush; it happens one little mistaken 
choice at a time.  

Nathan Myers
ncm at cantrip dot org