www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - a thought about std.stream

reply BCS <BCS_member pathlink.com> writes:
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
Sep 01 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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.
Sep 01 2005
parent reply Marcello Gnani <Marcello_member pathlink.com> writes:
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
Sep 02 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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.
Sep 02 2005