The InputStream and OutputStream interfaces are all but unusable because they have such a huge number of methods to implements, however most of them are implemented by the Stream class in a vary abstract way (all build on 4 or 5 low level methods). This is all well and good until you want to implement Input/OutputStream with some other class (Thread in my case)

Why not put all of those function in a pair of mixins? Then anyone who needs to make a stream like object could just implement the half dozen low level things and mix in a big chunk of code.


class ThreadStream : InputStream OutputStream Thread
{
	mixin InputMixin!();
	mixin OutputMixin!();

	size_t readBlock(void* buffer, size_t size){...}
	size_t writeBlock(void* buffer, size_t size){...}
	ulong seek(long offset, SeekPos whence){...}
}

BCS wrote:
> The InputStream and OutputStream interfaces are all but unusable because they have such a huge number of methods to implements, however most of them are implemented by the Stream class in a vary abstract way (all build on 4 or 5 low level methods). This is all well and good until you want to implement Input/OutputStream with some other class (Thread in my case)
> 
> Why not put all of those function in a pair of mixins? Then anyone who needs to make a stream like object could just implement the half dozen low level things and mix in a big chunk of code.

You mean like this?

http://www.invisibleduck.org/~sean/code/stream.d


Sean

Sean Kelly wrote:
> BCS wrote:
>> The InputStream and OutputStream interfaces are all but unusable because they have such a huge number of methods to implements, however most of them are implemented by the Stream class in a vary abstract way (all build on 4 or 5 low level methods). This is all well and good until you want to implement Input/OutputStream with some other class (Thread in my case)
>>
>> Why not put all of those function in a pair of mixins? Then anyone who needs to make a stream like object could just implement the half dozen low level things and mix in a big chunk of code.
> 
> You mean like this?
> 
> http://www.invisibleduck.org/~sean/code/stream.d
> 
> 
> Sean

More or less that type of thing. I'm thinking the same philosophy could be applied to std.stream without braking any existing code.

BCS wrote:
> Sean Kelly wrote:
>> BCS wrote:
>>> The InputStream and OutputStream interfaces are all but unusable because they have such a huge number of methods to implements, however most of them are implemented by the Stream class in a vary abstract way (all build on 4 or 5 low level methods). This is all well and good until you want to implement Input/OutputStream with some other class (Thread in my case)
>>>
>>> Why not put all of those function in a pair of mixins? Then anyone who needs to make a stream like object could just implement the half dozen low level things and mix in a big chunk of code.
>>
>> You mean like this?
>>
>> http://www.invisibleduck.org/~sean/code/stream.d
> 
> More or less that type of thing. I'm thinking the same philosophy could be applied to std.stream without braking any existing code.

Yup.  I just used that as an example because I had it lying around.


Sean

"BCS" <BCS@pathilink.com> wrote in message news:emv92t$2c5$2@digitaldaemon.com...
> The InputStream and OutputStream interfaces are all but unusable because they have such a huge number of methods to implements, however most of them are implemented by the Stream class in a vary abstract way (all build on 4 or 5 low level methods). This is all well and good until you want to implement Input/OutputStream with some other class (Thread in my case)
>
> Why not put all of those function in a pair of mixins? Then anyone who needs to make a stream like object could just implement the half dozen low level things and mix in a big chunk of code.
>
>
> class ThreadStream : InputStream OutputStream Thread
> {
> mixin InputMixin!();
> mixin OutputMixin!();
>
> size_t readBlock(void* buffer, size_t size){...}
> size_t writeBlock(void* buffer, size_t size){...}
> ulong seek(long offset, SeekPos whence){...}
> }

I tried that once briefly and ran into scoping issues since mixins can't see private functions elsewhere and vice versa. I didn't try very hard, though. It would be great to see a serious attempt at it.

-Ben