2009/11/27 Colin Putney <cputney at wiresong.ca>:
>
> On 26-Nov-09, at 2:48 PM, Nicolas Cellier wrote:
>
>> The path to a cleaner/faster stream library is longer than just this
>> little step.
>> Beside testing, we'd have to refactor the hierarchy, insulate all
>> instance variables, and delegate as much as possible as Igor
>> suggested.
>> We'd better continue on the cleaning path and not just add another
>> FileStream subclass complexifying a bit more an unecessarily complex
>> library.
>
> I've been thinking about this too. For Filesystem, I've only implemented
> very basic stream functionality so far. But I do intend to develop its
> stream functionality further, and to go in a very different direction from
> the existing design. Some design elements:
>
> - Using handles to decouple the streams from the storage they're operating
> on. The same stream class should be able to read or write to collections,
> sockets, files etc.
>
> - Separating ReadStream from WriteStream. I find code that both reads and
> writes to a particular stream to be very rare in practice, and in cases
> where it does happen, reading and writing are separate activities and using
> separate streams wouldn't introduce problems. On the other hand, a lot of
> the complexity in the existing hierarchy stems from the mingling of read and
> write functionality.
>

Yes, mostly a read-append stream usage for change log...
However, a buffered implementation will be difficult with separate
read/write buffers in the rare case we need read/write capabilities:
writing might trash the read buffer, so they are not independent.

> - Simplified protocols. The existing stream classes have accumulated a lot
> of cruft that should be implemented as objects use streams rather than being
> streams themselves. Examples include fileIn, fileOut, RefrenceStream etc.
>

Yes, packaging and modularization of core...

> - Composition rather than inheritance. As I go about implementing string
> encoding, buffering, compression etc. I plan to enable the creation of
> stream pipelines to provide combinations of functionality. Instead of
> implementing BufferedUtf8DelfateFilestream, I want to create a sequence of
> streams like this:
>
>        WriteStream -> Utf8Encoder-> DeflateCompressor -> Buffer -> Handle
>

Agree again

> - Grow the new streams parallel to the existing ones. Rather than trying to
> maintain backwards compatibility, leave the old streams in place and
> continue to improve them while the new ones are being developed. Migration
> to the new streams can happen gradually. If the new streams don't attract
> any users, obviously I'm on the wrong track. :-)
>
> So I've been watching your cleanup efforts with interest, particularly the
> buffering stuff. Keep it up!
>

Obviously, it's just a piece of a larger puzzle.

> Colin
>
>

Nicolas