How about removing conduit getter from IOStream interface?

korDen Joined: 03/12/08 Posts: 13

Posted: 08/31/08 12:17:17 Modified: 09/02/08 16:23:09 First, I don't like that InputStream? subclasses from IOStream. I think it should get renamed. Stream is of my personal preference. An InputStream? *is* a stream after all! interface InputStream : Stream // looks *much* better to me { } Second, is there any reason behind having a conduit getter in a (IO)Stream interface? Eof and close() are clearly belong to it. But conduit?? I think it should be as follows: interface Stream { enum : uint { Eof = uint.max /// the End-of-Flow identifer } void close (); } Let me explain why I ask for it. Suppose I opened a file with both read and write access. And I want to pass an instance of it to some user function. However, I want to ensure that he won't write to the file. That's why I pass a InputStream? pointer to it: void someUserFunc(InputStream inputStream); FileConduit fileConduit = ...; someUserFunc(fileConduit.input()); // Yes, I know it is implicitly castable But what if user does this: void someUserFunc(InputStream inputStream) { IOStream stream = inputStream; IConduit conduit = inputStream.conduit(); OutputStream outputStream = conduit.output(); // A-ha! outputStream.write(...); }