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

[Nathan Myers]

On Fri, Jan 04, 2002 at 04:13:34PM +0100, Gabriel Dos Reis wrote:
> "jon [tm]" <cow@compsoc.man.ac.uk> writes:
> 
> | From a lowly user's point of view, I prefer suffixed headers, if only
> | because a number of editors I use won't automatically do syntax
> | highlighting on a file without a suffix, so if I open up ext/memory
> | to see what extensions are available, or check the prototype for a
> | function (usually quicker than referring to the docs if it's just a
> | check) then my editor won't highlight it.
> 
> Then, what you need is not a suffxed file but a documentation of the
> available features.  
> 
> Looking into the implementations isn't something we promote, and I
> don't think we should do so.

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

Dependence on correctly-chosen filename extensions is pervasive, 
as I noted, and not limited to Make.  The Make problem (if problem
it still is) was a minor symptom of a larger problem.

It is contemptuous to suggest to people that they should go through 
a rigmarole to tell their editor the file type every time they open 
a file, or tell them to use the "right" editor.  The industry standard 
solution to file type problems is to observe the filename extension
convention.  Violating that convention brings back all the problems 
it had solved.  For elegance, Apple has (and Be had) "resource forks".  
In their absence we properly rely on filename extensions.

The extensionless names in ext/ such as hash_map were predicated on 
the assumption that they would be adopted shortly into the standard.
That assumption doesn't apply to other names in ext/, and may not 
reasonably apply even to those.

We can support backward compatibility with older releases that supplied 
extensionless names in ext/ by sub-including, or by symbolic links.
Old mistakes don't justify new mistakes.  

As it turns out, the hash components in ext/ don't closely resemble 
what will be adopted in the next standard anyhow.  The less they 
resemble standard components in form, the better.  Eventually they
will be enough of an embarrassment that we will want to move them 
to backward/.

Nathan Myers
ncm at cantrip dot org