A recent discussion with ROS_Guy on IRC prompted me to start toying with the idea of a completely object-oriented system.
I implemented a few test classes, and it was written in a combination of C and C++ (the main interface was C.) Basically you'd have objects and classes, as with OO programming.
However, the difference here is that files would be object instances, and to use a file you'd just "import" the object. The system would then automatically load the file handler for that object. By default, a "class" handler allows special DLLs to be loaded that contain a class definition (not in the C++ sense - it was a table of action names with addresses). In effect, a class in this case would've been an instance to begin with (an instance of the CLASS object.)
Anyway, the basic outcome was to be that you could effectively say "I want to open this database" and it'd find the database object (say, database.mdb), and then find the class type based on the extension (and maybe a few other parameters - like functions within it, as some apps share extension types, I've noticed.) This class would then be instantiated in a special way which would effectively subclass it.
This would result in a standard interface to the data within the file, as you could use the methods presented by the file handling class to manipulate the file.
To take another example, WAV MP3 OGG etc... All audio formats. All could have a common interface, so any program could read from and write to these files seamlessly, and the handler would handle the compression/decompression.
And to take things even further, a polymorphic file system could be employed. By that, I mean a file system that could change the file types "on-the-fly". So if you go to view all WAV files, you'll see WAV versions of your MP3s for example.
"Won't this take a lot of time and disk space?" I hear you ask... Well, no. The files wouldn't actually *be* files... They'd just be records pointing to the same piece of data on disk (the actual original file), with some information about the file, such as the original format, and what kind of file it is (eg: media/audio/wave.) Then, when an application accesses the file as a different type, it gets converted on-the-fly.
While this isn't really useful for WAV->MP3->WAV situations (eg, opening an MP3 in a sound editor, from what was originally a WAV file), it is more useful in the sense you could open an MP3 in Sound Recorder, as a WAV file!
And, with the correct file handlers, you could maybe open a Word document in Notepad (with a lot of filtering of graphics, etc. obviously) or maybe even open emails in Notepad.
I experimented with these ideas, and came up with a half-hearted effort that sort of worked but had a lot of limitations and was quite a kludge. However, should it be implemented properly (even just as a file system idea and not a complete OO system), I think it could go far.
A similar idea I had for the OO system was to have a socket handler for networking, too. So you could write an IM client that uses say, the MSN Messenger protocol handler, and that handler would have an identical (or near-identical) interface to the ICQ handler.
Maybe this would be something to look into?