I just wanted to drop a line in while you're wrapping up 10.1 and say that after a lot of thought and debate with friends, and research telling me how you have implemented it, that the feature of hidden filename extensions in 10.1 is actually not only the way it should be, but an ingenious step.

It can't be denied that loading file-type information into the filename is an ugly hack, and the world would have been better off without it (oh, what a world it would be if Apple had dominated in the 80s and 90s!)... but it also can't be denied that the crappy way that Windows has designed their file-typing system is the Way It Works now, and holding to Apple's (superior) system out of stubbornness would just deepen people's uncertainty about the platform. So I see the wisdom in adopting the idiom.

But more heartily, I applaud the way Apple is *doing* it. If it's possible to go about implementing such an awful feature the "right" way, it's the way Apple has done it: by making the extension into a piece of meta-data that's stored along with the filename, turned off or on at the user's whim, on a per-file basis rather than globally. In effect it's as if the extension were just an associated bit of data that gets called up and tacked on when the file is sent into a program (or out onto the Internet), which is a solution that many of us proposed when we first heard about the filename-extension brouhaha in the first place. So we won't have picture1.jpg.jpg or virus.gif.vbs problems, or so we can hope.

There are, of course, some complexities to watch out for. What about, for instance, filename collisions? Does 10.1 trap for collisions on the basename level, or based on what is displayed at the time, or on the full "unhidden" filename? In other words, can you have a picture1.gif and a picture1.jpg in the same folder? If so, under what conditions? I don't want to see my Mac succumb to the Windowsian stupidity of six files in a folder all called setup, differentiated only by their icons. The best solution would be to check for name collisions based upon the visible portions of filenames depending on whether the extension is being displayed or not (so picture1.gif and picture1.jpg could coexist, but not picture1 (with .gif hidden) and picture1 (with .jpg hidden)). And the global "always show filename extensions" switch should probably not try to affect that, because what if you turn it on, put some colliding files into a folder, and then turn it off? What should it do-- prompt you for an action on each offending file? No. That switch shouldn't try to address such a problem; it's an "Experts only" mode, as I see it now.

And of course, we must STILL make sure that type/creator codes are always set and honored by all applications, including Cocoa ones. The OS should still prefer those codes rather than the extension for type mapping, because it's so much more definitive and configurable than the Windows way. We must be able to associate files with certain apps based on the creator code. And the type code should override the extension. And the type/creator combination should always be used to generate the correct icon for the file, like it always has been. Filename extensions are a second-tier mechanism, something to assist in cross-platform compatibility, not something Mac users should have to get used to in their everyday lives.

In that vein, we must be sure that the table that maps extensions to file types is user-accessible and customizable. I need to be able to set what application should open my un-type-and-creatored .jpg files! And I need to be able to add new extension mappings for file types that Mac OS X doesn't know about! *And* I need the system to apply the appropriate type/creator codes to new files that enter the system, like it used to do with the Internet Control Panel. All this functionality can be encapsulated into a new system preference panel, "Extension Mappings" or some such. A table that lets me customize the extension-to-application mappings the OS knows about, add new ones, and associate type/creator codes to assign to files that only have extensions. That's a need that will not go away.

Finally, something that must be streamlined and thoroughly tested is what happens when you rename a file. Let's say you have a file called Diary.doc. What if you give it a name like My Diary 4.6.2000? If the new extension isn't recognized by the system, don't bother and frighten the user with dialog boxes with dire warnings about what might happen if you change the extension. Just make it My Diary 4.6.2000.doc and hide the .doc extension. But what if you have picture1.jpg and you rename it to picture1.gif? That's a trickier situation. Do you make it picture1.gif.jpg and hide the extension? That's what leads to things like virus.gif.vbs... it's clearly not a good way to go. But neither is it a good thing to sternly tell the user "Hey! Just by renaming the file, you're possibly going to screw up your system!" like Windows does. And renaming it canonically to picture1.gif will in fact break things-- that's no good, unless it sets type/creator codes to cover for it. So maybe what we need is some kind of automated mechanism that will flip the switch so the extension is always shown, if multiple recognized extensions are detected. Or better yet, have it so that when you rename the file, it ensures type/creator codes are set, and then renames it to picture1.gif with .jpg hidden. That way it would still functionally be a JPEG file, even for Windows users, but it would still display the name the user gave it. Of course, Windows users with extensions hidden would only see picture1.gif, but eh...

It's a rather messy situation, but I want to thank everybody at Apple for taking these things into account. It's a thankless job, I'm sure-- and the urgently-worded feedback messages I've been sending have not helped matters, I imagine. I apologize for hounding you on this subject, but I do think it's vitally important to the future of the Mac that it be handled properly. However, I'm now much more willing to accept that Apple has an intelligent plan for it, and I have faith in the product designers and engineers and their ability to see it through.

Thank you...

Brian