What's better is dong it right. Like HTML requests or Email Messages, file systems should allow arbitrary metadata fields on files. Some standardized for specific purposes, such as file type. Others available for whatever the file format, program, or user wants.

For example, MP3's ID3 tags shouldn't have to be stuck into the content. They are metadata and should be represented as such.

The BeOS file system had this right. It just didn't have enough market presence to make a difference.

That simply means that these other systems share the same brokenness of not having a filetype as one of their metadata fields. Again it doesn't make confusing name and type in a single field a good thing.

And BTW if you're assigning responsibility, DOS just copied CP/M's naming convention of 8.3.

First of all whatever you do can't be worse than file extensions because they are a free for all, and clashes, especially of 3 letter types are common.

Secondly, it's a solved problem. MIME types have both standard types defined, plus a defined process for vendor extensions. Yes, via IANA.

Thirdly file types which have no additional requirements for registration, yet unambiguous are easy, by simply prefixing them with an already registered domain (usually reversed). e.g. com.google.whateverthefuckgooglewanttocalltheirnewfiletype.

Right. It's a single stack of software sold as an OS. If the extension is used as a concealed file type by one part (desktop) then the name is effectively that, and it's a bug to allow more than one the same.

I'm not saying that Windows should actually be modified to prevent this. I'm just pointing out the illogicalities that using file extensions as file types gives.

BTW, as a rif on your suggestion, EPOC32 (that because Symbian) had an interesting angle. FIle types were given by file system extensions "recognisers" that could tell file types by arbitrary means. So they could look at file contents (generally the first sector of a file) or file name. So you could look for an HTML header say, Indeed most file types have recognisable headers within them. For example I did a Gameboy emulator, and I wrote a recogniser to go with it that recognised Gameboy games by the string "(C)Nintendo" which was always at a particular offset in the file. Which my colleague found rather amusing.

In a lesser way, *nix tells the types of executables by examining the first part of the content. e.g #!/usr/bin/python

You can't claim authority here. I was programming assembler as far back as 1983.

What you mean by "misused" here is using the C++ parts of C++. Because if you do, you will almost certainly be slower than C. For example virtual functions require an extra level of indirection over C function calls.

And when it doesn't matter then no need to stray from Obj-c. There's no reason to have 2 OO languages in a project.

Shut the fuck up. I've already said more than once that the only reason people use C++ in iOS or OSX projects is when they are leveraging a library that's in C++.

You seem to be very much agreeing.

And again your thinking is being limited by Windows. It's like dismissing pneumatic tyres because they don't fit on horses hooves.

Whilst we could debate the usefulness or not of file types being in your face, there was precisely nothing of that suggestion in my post. As I've already told you in the post you're replying to.

And C++ isn't as portable as C. Or as efficient.

But there are downsides to using it in this capacity rather than C. Which is why few do so.

1) Good but not as good as C.
2) But it's an unnecessary third layer. Obj-C has the objects. C has the speed and compatibility. What do you need a third layer for?
3) Indeed. So virtually no one uses it in this scenario.

Only time I see it used is when it's a library that was written in C++ on another platform and is simply being used on a Mac.

Who says it's hidden? There's nothing special about a a filename that means it is visible in the UI. As this very story shows.

You're thinking is being limited by what you are used to. You're lacking imagination to envisage better alternatives.

Expecting users to notice the filetype and act cautiously is not much of a security technique. Security should be imposed by the system, and the system can see all of the filename and all other metadata and contents too.

They can. The user is guaranteed that the name of the file is what the filename is. They can have 100% trust in that.

You seem to be confusing that with file types. Your name is jedidiah (or at least your alias). But that's not your file type. I assume you're human. Yet we don't call you jedidiah.human.

Geeks et angry over perceived limitations in GUIs. Yet they give the limitations of a CLI a pass. Here the fault is with CLIs. How braindead that a valid file character is used as a separator.

Elimination of clutter focusses the mind. Whilst to the hoards of sysadmins and IT workers that congregate round here file types aren't clutter, to users they are.

That doesn't demonstrate it's dangerous to hide stuff.
It shows first of all that it's a bad idea to have file type encoded in the filename. But secondly, OSX doesn't have this danger, whilst still allowing hiding filetypes in more normal situations. i.e. If you have hidden filetypes, a filename that have a double file extension will still display in full to highlight the attempt.