Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Even worse - extensions == "chmod +x" ?!? (Score 1) 562

by BasilBrush (#49187413) Attached to: Why We Should Stop Hiding File-Name Extensions

Alternatively, you can say that file exension is metadata distinct from the name

No you can't. They are set and read together in both the primary APIs, and virtually every UI.

And yes, it is a crappy way to do it, but it's the one that became the de facto standard. Changing it now is very costly, and cannot be done unilaterally.

Oh it'll certainly change. It's just a matter of when. The precursors are already there. UIs hiding the file extensions from users. Internet protocols using mime types rather than file extensions.

It'd certainly be perfectly possible to have an OS and file system right now that did it and interoperated perfectly well with the rest of the world. It's just a matter of defaulting to file extensions when communicating with something dumb.

Comment: Re:C++ important on Apple too (Score 1) 395

For example virtual functions require an extra level of indirection over C function calls.

You are wrong, doubly wrong actually.
(1) If the class is not using inheritance you don't get the indirection.

If you're not using inheritance then you won't use a virtual function. (Did you read what I wrote?)

If you need the abstraction/indirection then you are simply doing your own indirection manually in C code.

Not necessarily. Just because you might do things with objects in C++ doesn't mean the code would be written as pseudo objects in C.

You missed the point. Its not that google is using C++ libraries, its that they are writing their libraries in C++.

Portable libraries. It makes no fucking difference whether the library was written within the same conglomerate.

Plus you are doubly wrong again since people also use C++ in Apple targets for portability.

Are you hard of thinking? That was the one exception I made. Using portable libraries. However if the library intended to be portable starts on OSX, then it's virtually always written in C.

Comment: Re:Good operating systems Dont. (Score 1) 562

by BasilBrush (#49187329) Attached to: Why We Should Stop Hiding File-Name Extensions

Mac OS did too. Not as a mimetype, but at least separate from the name.

And BeOS died for reasons other than this.

The compatibility issue used to be a problem when we all shared physical media. These days as most remote files come from the internet, and generally has metadata when it does so, this is perfectly workable. e.g. Anything that comes over HTTP has a MIME-TYPE provided the server is not broken.

Comment: Re:Even worse - extensions == "chmod +x" ?!? (Score 1) 562

by BasilBrush (#49179573) Attached to: Why We Should Stop Hiding File-Name Extensions

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.

Comment: Re:Even worse - extensions == "chmod +x" ?!? (Score 1) 562

by BasilBrush (#49179535) Attached to: Why We Should Stop Hiding File-Name Extensions

In principle file type(s) would be separate metadata, but in practice using a file name extension works out much better. I can take some pictures on my android device, which saves them to a FAT-formatted SD card, then FTP them it to my windows box, collect them in a .zip then attach that as an email, extract them in OS/X, and it still knows they are jpegs. That's only possible because the type is part of the name. Otherwise FAT would have lost it, FTP would have lost it, the zip program would have lost it, and the email program would have lost it again.

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.

Comment: Re:Even worse - extensions == "chmod +x" ?!? (Score 1) 562

by BasilBrush (#49179515) Attached to: Why We Should Stop Hiding File-Name Extensions

With whom would values of the file type field be registered? IANA?

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.

Comment: Re:Yes, I agree (Score 1) 562

by BasilBrush (#49179159) Attached to: Why We Should Stop Hiding File-Name Extensions

Certainly they are not the same file, but the OS is not at fault here. The OS (well, technically, the Windows filesystem) properly keeps track of the full filename -- it is the Windows desktop user interface that is at fault by hiding information.

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

Comment: Re:C++ important on Apple too (Score 0) 395

Speaking as an assembly language programmer

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

Can C++ classes and templates be misused, absolutely, but that is a programmer's error not the language's.

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.

**IF** and when it matters code can be written in a C'ish manner, possibly with minor use of classes or templates, and the generated code will not suffer.

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.

Again, a straw man, and again you have been misinformed with respect to C++'s usage. Ex: "C++ is the main development language used by many of Google's open-source projects."

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++.

Comment: Re:Good operating systems Dont. (Score 1) 562

by BasilBrush (#49174785) Attached to: Why We Should Stop Hiding File-Name Extensions

No, I just envisage what will happen when this is introduced on Windows.

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

But adding metadata to files that is not "in your face" is not the best suggestion I've seen for that.

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.

Comment: Re:C++ important on Apple too (Score 1) 395

Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.

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.

Comment: Re:Good operating systems Dont. (Score 1) 562

by BasilBrush (#49174391) Attached to: Why We Should Stop Hiding File-Name Extensions

some meta-information that's probably hidden by default.

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.

Comment: Re:That's the problem (Score 2) 562

by BasilBrush (#49174265) Attached to: Why We Should Stop Hiding File-Name Extensions

No. A user should be able to trust the name of the file.

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.

Take your work seriously but never take yourself seriously; and do not take what happens either to yourself or your work seriously. -- Booth Tarkington

Working...