[squeak-dev] Faster FileStream experiments

Colin Putney cputney at wiresong.ca
Fri Nov 27 04:56:08 UTC 2009


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.

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

- 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

- 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!

Colin



More information about the Squeak-dev mailing list