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.

surferjeff@excite.com wrote:
> 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.
> 
> 

Phobos sucks. There I said it. :-)

In other news, there is a library called Mango on www.dsource.org which you may find useful.

<surferjeff@excite.com> wrote in message news:dtribg$eui$1@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.

In article <dtsbc3$1c8g$1@digitaldaemon.com>, Ben Hinkle says...
>
>
><surferjeff@excite.com> wrote in message news:dtribg$eui$1@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.

surferjeff@excite.com wrote:
> 
> 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.

Something like:

    class MyStreamImpl()
    {
        void readBlock();
        void writeBlock();
        seek();
    }

    class Stream( Impl )
    {
        mixin Impl!() impl;
        alias impl.readBlock readBlock;
        alias impl.writeBlock writeBlock;
        alias impl.seek seek;
        ...
    }

    alias Stream!(MyStreamImpl) MyStream;


Sean

<surferjeff@excite.com> wrote in message news:dvaupb$1ok0$1@digitaldaemon.com...
> In article <dtsbc3$1c8g$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>
>><surferjeff@excite.com> wrote in message news:dtribg$eui$1@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.

Sure, one can trade-off flexibility and ease-of-use. For example
std.stream.File could just implement the 3 pure virtual methods and then
user code would write
 Stream file = new Stream(new File("foo.txt"));
So the flexibility of multiple classes and interfaces results in user code
having to do more to hook things up. There are many many ways to slice
things up. At one point I posted a suggestion to have a Stream subclass that
accepted delegates for the 3 methods and then one wouldn't have to write a
class at all - one can just write 3 nested functions and pass those to the
constructor. For example
 void foo() {
    char buf[100];
    size_t readBlock(void* buffer, size_t size) {
       ... do something with buf ...
    }
    .. 2 more nested functions for writeBlock and seek ...
    Stream s = new DelegateStream(&readBlock, &writeBlock, &seek);
    ... use s as any other stream ...
    }
but I don't recall that suggestion getting any lovin' so I dropped it.
I think if you have concrete suggestions go ahead and post them, see what
kind of response you get and based on the response make changes and submit
them to Walter and see how things go.

-Ben