Re: Mac OS X 10.1 File Name Extension Guidelines
Re: Mac OS X 10.1 File Name Extension Guidelines
- Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
- From: "Neal A. Crocker" <email@hidden>
- Date: Sun, 9 Sep 2001 21:21:17 -0700
Date: Sun, 9 Sep 2001 13:47:04 -0700
Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
Cc: Bill Chin <email@hidden>, <email@hidden>
To: Brendan Younger <email@hidden>
From: "John C. Randolph" <email@hidden>
On Sunday, September 9, 2001, at 10:49 AM, Brendan Younger wrote:
> On Sunday, September 9, 2001, at 12:17 PM, Bill Chin wrote:
>
>> On Sunday, September 9, 2001, at 10:13 AM, Mark Munz wrote:
>>
>>> Wait, isn't putting the definition of what type of document I'm
>>> dealing with
>>> a throwback to the early years when disk space was expensive and in
>>> short
>>> supply, when saving 4 bytes was crucial, when we used .txt to define
>>> a text
>>> file and such. Apparently we haven't come very far.
>>
>> Actually, with file name extensions, I can create an application that
>> uses .hypertext as an extension under Mac OS X today. With current
>> HFS+ implementation, we're limited to 4 character type codes (HTXT).
>> Which one is more limiting?
>>
>> And you're right. We haven't come very far.
>
> The fact that it is a four "character" code does not in *any* way limit
> it.
Of course it does. It's supposed to be a menemonic
no, it's not (as far as I know). Four character codes are used in
Mac APIs for a great variety things besides file types and these APIs
go to great lengths (using "#define, enum statements and other
language mechanisms) to supply (i.e. "expose" as part of the API)
semantically meaningful symbols that represent four letter codes
which are often obscure. For intance, in the CarbonEvents.h, a
number of enum constants of the form kEventParam* are defined which
represent four letter codes. For many of these codes, seeing the
code used raw in a program would make for very obscure source because
there's often very little semantic info that can be packed into four
letters. The defined enum constants, on the other hand, are very
semantically rich. Also, In all the sample code I've seen in
documentation for Mac APIs, four letter codes are given semantically
rich representations which are in turn used in every instance where
the codes are needed. I've even seen this trick applied to file type
four letter codes in sample code for document manipulating
applications.
(for the programmer at least), and the fact that I *could* use
"67&h" for my type and "!@g1"
for my creator code doesn't help when I have a conflict with someone
else's use of a nice, memorable four-letter type like "TEXT".
Neal.