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

[Nathan Myers]

On Fri, Jan 04, 2002 at 09:34:06PM +0100, Gabriel Dos Reis wrote:
> Nathan Myers <ncm-nospam@cantrip.org> writes:
> | Gabriel Dos Reis wrote:
> | > "jon [tm]" <cow@compsoc.man.ac.uk> writes:
> | > | From a lowly user's point of view, I prefer suffixed headers...
> | > Looking into the implementations isn't something we promote...
> | 
> | *Self-deception alert!*
> | 
> | Reading the source is something we *do* promote, because it encourages 
> | participation.  (What we don't promote is depending on nonportable
> | features found there.)
> 
> I don't want to make a big deal of the issue because I don't think it
> is really an issue.  

I know you would prefer to minimize the problem.  That's part of problem.

> I appreciated your very detailed description of
> when and how the Make problem you mentioned can occur.  However, I
> think you'll agree with me that those routes no longer (ever?) cross
> the path we take to build the library.  

As I noted, the example was not typical usage but just the easiest
way to get Make to delete a file.  I am almost certain that what I wrote 
this week is not what happened, back then.

In any case, Make troubles are just a symptom.  So are editor-mode
troubles.

The point of the std/header -> bits/std_header.h apparatus was
to contain the extensionless names to a single directory that no 
one would ever need to look in under normal circumstances.  In the 
absence of compiler support, it was the closest that could be got 
to the committee's intent.
 
> On the other hand, I consider that consistency is far more important
> than syntax-highlighting.  That is just my opinion, you may disagree
> but then I don't think that should ring a self-deception alert bell...

No, you are still deep in self-deception territory.  Think: 

--
1. What has changed since filename extensions were adopted?
  Particularly, what happened to make them unnecessary?

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".)

When we talk about Make semantics, or editors with syntax markup,
we're just talking about specific examples of tools observing and
acting on a universal convention.  For any given example it's likely 
that some workaround (.PRECIOUS, -*- tags) can be discovered to 
mitigate breakage.  But why break things in the first place?

What workaround would you propose for find and grep, for use when
selecting files to scan?  Or should we not use such tools any more?
(This question is deadly serious, and cuts to the heart of the
real problem we have been dancing around.)

2. Is the rest of the world (outside the C++ standard library) abandoning
  filename extensions?

Far from it.  Systems that support file metadata (such as Be and Apple)
have instead come to accommodate filename extensions too, in their stead.

--

The consistency argument is classic self-deception: it begs the 
question, consistent with what?  Consistent with the whole wide 
world, or consistent with a special case introduced by a tiny group 
for insular committee reasons?

Extensionless header names was a clever committee solution to a 
committee problem.  It was left to us to interface it with the 
real world of files.  A well-known, short list of extensionless 
symbolic-link names identified in the standard is a limited evil.  
A convention adopted in the name of a spurious "consistency" with 
that short list is an unlimited evil.

Nathan Myers
ncm at cantrip dot org