Thread overview | ||||||
---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marcello Gnani | "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. |
Copyright © 1999-2021 by the D Language Foundation