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?