"File types"

[Don]

Zane H. Healy wrote:
>> When did the notion of "file types" creep into computing?
>> Hmmm... poorly phrased.  How about: "When did the notion of
>> file *associations* (?) creep in?".
> 
> I think that this is a logical extension of a Graphical User Interface.  As
> such Apple is likely to be the one to "blame" for it.

Well, there have been "conventions" since The Dawn of Time
for *naming* files.  But, those have always been just
*conventions* and not really "enforceable" (nor ENFORCED!).
Personally, I dislike the idea of having a name carry "type"
information (whether that be the name of a file, variable,
procedure/method/function, etc.).  My name isn't:

offspring_Male_mother_Mary_father_...._Don

yet, people *somehow* seem to know who I am  :-/  So, I don't
see why other naming *conventions* should carry all that
baggage as well.

>> persists?  Has Apple abandoned the "hidden" file creator
>> attributes of earlier MacOS in newer OS's (e.g., OS X)?
>> Or, have they bowed to user pressure and implemented a
>> "me-too" scheme?
> 
> Sadly Apple went with the NeXT way of doing things with Mac OS X.  There
> seems to be very little of the Classic Mac OS in Mac OS X.  While I think
> that getting rid of resource forks is a good thing, was it really necessary
> to drop the file creator attributes?  Very frequently I have files of a
> certain type .JPEG for example, where I want to open certain files of that
> type with one program, and others with another.  With the file creator
> attributes this worked just fine.  With the Microsoft & Mac OS X "one size
> fits all" attitude, only one app will be associated with *ALL* files with
> that extension.

Even in the limit case (i.e. only one application exists with which you
could use to "open" *all* JPEGs), is there still any reason why you
need to name a file:

PictureOfUsSkiing.<photograph>

Granted, you might have:

Skiing.<photograph>           // i.e. photo
Skiing.<expense_tabulation>   // i.e. spreadsheet
Skiing.<test>                 // i.e. invitation to ski trip
...

But, they could still all be *called* "Skiing" -- with some
other attribute (e.g. file creator) that actually differentiates
them.

So, it seems like the only reason to have that attribute
*visible* is because you want your directory listing
(graphical or otherwise) to be able to differentiate
between the N different "Skiing" files that you might have
(in that particular container).  I.e. so that you could
"select" (e.g., "click") the one that you are interested in.

Wouldn't, instead, a better (?) scheme be to show/list all
"Skiing" files as a single item and, when selected, prompt
the user for which *aspect* of "Skiing" he was interested in
(i.e. "Do you want to view the photo, see the expense summary
or read the invitation?").

Note that this (above) is predicated on the assumption
that you would *allow* name collisions (overloading based on
the file name) and resolve them some other way.  If this
isn't allowed, then there would be no ambiguity and the
user would be free to pick what he/she wants to call the
file without someone imposing an artificial "file type" as
part of the namespace.

[N.B. *You* can get around the "file extension" problem by
creating your own file type for JPGs that you would like
to open with some *other* application.  But, it's an
inconvenience...]

So, I'm still wondering *why* this came to be (hence the
historical reference)