View mode: basic / threaded / horizontal-split · Log in · Help
September 01, 2005
a thought about std.stream
After perusing the std.stream code I found that all of the read() and write()
functions funnel down to the readBlock and writeBlock functions. This is done (I
assume) so that the full functionality of the read/write set is available to
derived classes and all they need to do is defined two function. If this is the
case, then this should be documented and standardized. If this isn’t done,
another implementation could use the getc/putc pair (for example) as the
single-point-of-access and break a lot of code.

Just my .02
September 01, 2005
Re: a thought about std.stream
"BCS" <BCS_member@pathlink.com> wrote in message 
news:df7m0v$1i8j$1@digitaldaemon.com...
> After perusing the std.stream code I found that all of the read() and 
> write()
> functions funnel down to the readBlock and writeBlock functions. This is 
> done (I
> assume) so that the full functionality of the read/write set is available 
> to
> derived classes and all they need to do is defined two function. If this 
> is the
> case, then this should be documented and standardized. If this isn't done,
> another implementation could use the getc/putc pair (for example) as the
> single-point-of-access and break a lot of code.
>
> Just my .02

Good idea. Currently the std.stream doc doesn't mention how a subclass 
should work. I have some changes sent to Walter that adds another abstract 
class FilterStream that users can subclass. I don't know what he's going to 
do with those changes, though.
September 02, 2005
Re: a thought about std.stream
In article <df80up$1vah$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"BCS" <BCS_member@pathlink.com> wrote in message 
>news:df7m0v$1i8j$1@digitaldaemon.com...
>> After perusing the std.stream code I found that all of the read() and 
>> write()
>> functions funnel down to the readBlock and writeBlock functions. This is 
>> done (I
>> assume) so that the full functionality of the read/write set is available 
>> to
>> derived classes and all they need to do is defined two function. If this 
>> is the
>> case, then this should be documented and standardized. If this isn't done,
>> another implementation could use the getc/putc pair (for example) as the
>> single-point-of-access and break a lot of code.
>>
>> Just my .02
>
>Good idea. Currently the std.stream doc doesn't mention how a subclass 
>should work. I have some changes sent to Walter that adds another abstract 
>class FilterStream that users can subclass. I don't know what he's going to 
>do with those changes, though. 
>

I would add an interface and, if needed or desired, a template implementation to
mix in, instead of an abstract class.

Let's say I find in std.stream SpecializedFileStream : AbstractFileStream and I
want to implement a new hierachy of streams (the FooStreams);
If i want to supply my own AbstractFooFileStream
(coding AbstractFooFileStream : AbstractFileStream)
then I am in trouble, because I have to choice wheter coding
1) SpecializedFooFileStream : AbstractFooFileStream
(But this would mean SpecializedFooFileStream is not a SpecializedFileStream)
or coding
2) SpecializedFooFileStream : SpecializedFileStream
(But this would mean SpecializedFooFileStream is not an AbstractFooFileStream)

If I find, instead, in std.stream SpecializedFileStream : InterfaceFileStream
(eventually with some TemplateFileStreamDefaultOfSomeMethod to mix in), I can
code InterfaceFooFileStream : InterfaceFileStream, eventually supply my own
additional templates to mix in, and then code:
SpecializedFooFileStream : SpecializedFileStream, InterfaceFooFileStream

The SpecializedFooFileStream class would then be a SpecializedFileStream, but
would offer InterfaceFooFileStream (and, because of inheritance,
InterfaceFileStream) as well.

Marcello Gnani
bramarcello_gnani@tiscali.itket
September 02, 2005
Re: a thought about std.stream
"Marcello Gnani" <Marcello_member@pathlink.com> wrote in message 
news:df8vml$2vgl$1@digitaldaemon.com...
> In article <df80up$1vah$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>
>>"BCS" <BCS_member@pathlink.com> wrote in message
>>news:df7m0v$1i8j$1@digitaldaemon.com...
>>> After perusing the std.stream code I found that all of the read() and
>>> write()
>>> functions funnel down to the readBlock and writeBlock functions. This is
>>> done (I
>>> assume) so that the full functionality of the read/write set is 
>>> available
>>> to
>>> derived classes and all they need to do is defined two function. If this
>>> is the
>>> case, then this should be documented and standardized. If this isn't 
>>> done,
>>> another implementation could use the getc/putc pair (for example) as the
>>> single-point-of-access and break a lot of code.
>>>
>>> Just my .02
>>
>>Good idea. Currently the std.stream doc doesn't mention how a subclass
>>should work. I have some changes sent to Walter that adds another abstract
>>class FilterStream that users can subclass. I don't know what he's going 
>>to
>>do with those changes, though.
>>
>
> I would add an interface and, if needed or desired, a template 
> implementation to
> mix in, instead of an abstract class.
>
> Let's say I find in std.stream SpecializedFileStream : AbstractFileStream 
> and I
> want to implement a new hierachy of streams (the FooStreams);
> If i want to supply my own AbstractFooFileStream
> (coding AbstractFooFileStream : AbstractFileStream)
> then I am in trouble, because I have to choice wheter coding
> 1) SpecializedFooFileStream : AbstractFooFileStream
> (But this would mean SpecializedFooFileStream is not a 
> SpecializedFileStream)
> or coding
> 2) SpecializedFooFileStream : SpecializedFileStream
> (But this would mean SpecializedFooFileStream is not an 
> AbstractFooFileStream)
>
> If I find, instead, in std.stream SpecializedFileStream : 
> InterfaceFileStream
> (eventually with some TemplateFileStreamDefaultOfSomeMethod to mix in), I 
> can
> code InterfaceFooFileStream : InterfaceFileStream, eventually supply my 
> own
> additional templates to mix in, and then code:
> SpecializedFooFileStream : SpecializedFileStream, InterfaceFooFileStream
>
> The SpecializedFooFileStream class would then be a SpecializedFileStream, 
> but
> would offer InterfaceFooFileStream (and, because of inheritance,
> InterfaceFileStream) as well.
>
> Marcello Gnani
> bramarcello_gnani@tiscali.itket

There are two interfaces InputStream and OutputStream and I have 
experimented myself with adding templates (something like MInputStream and 
MOutputStream where the M is for mixin) but IMHO the templates were not 
wieldy because
1) they would be big so anyone who wants to customize just one of the 
functions can't mixin the whole template. The alternative is to templatize 
lots of little pieces but the problem there is that the default 
implementation in Stream has dependencies between the functions and so these 
mixins would have to be used very carefully.
2) templates can't use "this" and a couple functions return this so users 
would have to supply a thisref property or something so that those functions 
could be mixed in. Plus mixing in overloaded functions required aliasing in 
the user code. The results were hacky enough that I haven't sent them to 
Walter. If someone wants to play around more that I have, though, they are 
welcome to. I'm just someone who like to change std.stream but anyone can 
send Walter stuff or post ideas here.
Top | Discussion index | About this forum | D home