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