Re: Extensionless headers

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

On Sat, Jan 05, 2002 at 11:29:13AM +0100, Gabriel Dos Reis wrote:
> Nathan Myers <ncm-nospam@cantrip.org> writes:
> > [...]

The "[...]" stands for lots of important questions still unanswered.
Please go back and explain why you cannot answer the hard questions.
 
> | 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.
> 
> If you're after .cc or .tcc files, those aren't changed.  Right?
> The remaining is the headers.

You are saying that there are no files in the libstdc++ archive
besides source files?  

If filenames stripped of the ".h" extension are good, why leave the
".cc" extensions in place?  Surely the directory they appear in
identifies them well enough...

> | > 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.
> 
> Tool for what exactly?

Tool for everything.  The Unix tradition involves using scripts for all 
kinds of jobs in software development.  I defy anyone to tabulate all 
the useful ones.

> Syntax highlighting? No, since the files were
> interpreted as C header files.  Find?  There are three types of files,
> headers, .cc and .tcc.  That settles the problem and its solution.
> And here, we're aren't inventing since evidence has been provided that
> industry-wide libraries are using the same scheme.

These purported "industry-wide" libraries are all rather newer than 
the libstdc++ project itself.  Nobody has enough experience with them 
to claim that the experiment has worked out well.

You are proposing this large change to fix *what* *problem*?  You have 
not identified any critical problem that justifies abandoning thirty 
years of experience in organizing files.  You have not identified a 
set of alternative approaches for dealing with this (unexpressed) 
problem.  You have not identified any comprehensive solution for all 
the new problems your "solution" creates, just incomplete workarounds 
for specific cases.  

The only justification you have offered for this large change is to
match an arbitrary policy in a standard committee that manifestly 
refused, on record, to consider any practical impact of applying the 
policy to actual file names -- because they were not specifying file
names at all!  

These glib "that settles" remarks only reveal the depth of self-deception
at work.  They don't settle anything.  It's not even your right to claim 
that they settle anything; it's up to the person you are proposing 
workarounds for to say whether they are satisfactory.

Nathan Myers
ncm at cantrip dot org