> I'm currently rolling an alternative Streams package, and I have to say, I keep thirsting for multiple inheritance. For I/O streams it makes a whole lot more sense, and offers a very elegant solution to splitting input and output. However, it's not going to happen. These mixins seem like they could desolve my frustration, though. But untill they're implemented, I'd love to see if one could work around the problem.

And why do you need to split an I/O class to input and output anyway? it is silly. Just provide a IODevice superclass with an input AND output interface, and have a File class which does I/O from files.

If the user tries to write from a read-only device, throw an exception. If the user tries to read from a write-only device, throw an exception.

Inside those read/write operations you would check anyway for I/O errors, so you could not say that you would save some code if multiple-inheritance was allowed.

This is much simpler:

IODevice
  |--File
  |--Socket
  |--Pipe

than:
IODevice:
  |--IFile------|
  |--OFile-----|
                   |-IOFile

A single File class also reflects what a file really is: an input/output device.

For me, it is quite frustrating to having to remember 'reader' classes and 'writer' classes and classes prefixed with 'i' and classes prefixed with 'o'. And I think it is silly. The only real benefit for such an API is to make sure that someone that indends to read from a file would indeed read from a file instead of writing to it...but if there was an error like this, it would be the first to be caught anyway...

Keep it simple!

I think that a restricted form of Multiple Inheritance (i.e. requiring author to explicitly show which function to inherit in cases of ambiguity), all other solutions use more code then is strictly necessary.