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: Mon, 10 Sep 2001 00:10:09 -0700
Subject: Re: Mac OS X 10.1 File Name Extension Guidelines
Cc: <email@hidden>
To: Brendan Younger <email@hidden>
From: Bill Chin <email@hidden>
On Sunday, September 9, 2001, at 01:49 PM, 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?
>>
> The fact that it is a four "character" code does not in *any* way limit
> it. It's implemented as a long int and can thus have up to 4294967295
> possible values. That is far more than will ever be needed.
Hmmm. Mark Munz was talking about saving disk space, "when saving 4
bytes was crucial" and that somehow file extensions was related to that.
My point is that file extensions, as implemented today, have a larger
potential namespace than the 4 character type codes, so disk space isn't
the issue. Of course, a 32 bit unsigned int does have a limit - you
stated it.
> Also, the fact that it is completely hidden from the user and only
> its manifestation is presented is a point for it over file extensions.
> (No one actually cares whether it's hTXT or HTXT or HTEX, a program
> that wants to know it's type just looks for the appropriate code. No
> aesthetic judgement is necessary.)
Ah, yeah. Of course, when you actually have to change it, you have to
remember the right number out of 4294967295 possible values, or worse,
picking the right one out of a list that scrolls forever. This
effectively makes the number of really useful values much lower. Unless
you want to be the developer that ships an application where users have
to change the type of a document to "@!(>" for the system to recognize
it properly.
In the Mac OS user experience, the average user never has to change
the code, or even see it, so they never have to remember it. In any
situation where they are offered an option to change the type of a
file by some application or utility, the Mac standard is that the
user is only offered human-readable options (which application
associates with file type codes behind the scenes where the user
never sees it.)
Neal.