Streams: an open discussion

[surferjeff at excite.com]

In article <dtsbc3$1c8g$1 at digitaldaemon.com>, Ben Hinkle says...
>
>
><surferjeff at excite.com> wrote in message 
>news:dtribg$eui$1 at digitaldaemon.com...
>> The interface for InputStream and OutputStream is huge.  I often have to 
>> create
>> my own streambufs in C++, which only requires implementing about 5 
>> methods.  If
>> I want to write my own class that implements InputStream, then I have to
>> implement about 50 methods, and another 50 if I want to implement 
>> OutputStream
>> too!
>>
>> It would useful if there were smaller interfaces.  For example, a read() 
>> method
>> and eof() for input, and that's it.  Then have a util class that takes one 
>> of
>> these small interfaces and implements the full 50 methods in the bigger
>> interface.
>>
>> Yes, I could do this in my own code, but I think many people will have to
>> re-invent this wheel in D, and each re-invention will be different and not
>> interchangeable.
>
>
>Subclass Stream or FilterStream. You'll probably have to override 3 methods: 
>readBlock, writeBlock and seek. The interfaces are primarily for users to 
>restrict their API - not for library writers to shoe-horn their classes 
>into. Look at any of the small stream classes in std.stream to get an idea 
>how easy it is to do. 
>
>

I see. Not so bad.  Thanks.

Instead of the "Inherit 20 methods, implement 3 pure virtual methods" approach,
how about "implement the same 3 pure virtual methods in an interface, pass the
interface to a class that uses it to implement the 20 methods."  I've used the
former pattern a lot in C++, and have found it difficult to reuse.  I recently
learned the latter pattern in Objective-C and Cocoa, and have found it much
easier to reuse.