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

"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.

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

"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.