The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,617 other followers

On the design of the Delphi TStream classes – why aren’t they decomposed better?

Posted by jpluimers on 2017/05/16

Ever since I started using Delphi more than 2 decades ago, I wondered about the design of the TStream classes, especially as “” by Duncan Murdoch from the DOS Turbo Pascal era (which I copied in the below gist) showed how to perform composition using streams.

Even though by now there is TStreamReader/TStreamWriter allowing some level of composition, it always bugged me that large parts of the resource handling and component (de)serialisation is in it (centred around ReadComponentRes/WriteComponentRes in stead of fully being in TFiler/TReader/TWriter or even further decomposed), that you cannot interrogate capabilities (like supporting seeking, length, directionality and such) and that a lot of overloads (for instance Read/ReadBuffer/ReadBufferData/Write/WriteBuffer/WriteBufferData) are still based on signed or 32-bit types (though it has improved back in the early days they were even signed 16-bit types).

I’m not the only one who wonders about this: Faster FileStream with TBufferedFileStream • DelphiABall mentioned a new Berlin piece the TStream hierarchy and – being in the field a lot longer – Stefan Glienke rightly asked why the buffering isn’t done with the decorator pattern like JclStreams does, and Asbjørn Heid chimed in with a very dense version of more gripes.

Even TZCompressionStream/TZDecompressionStream (though relatively new) aren’t doing composition really well (by not abstracting the compression/decompression from the write-only/read-only behaviour).

Now that all key players from the early TStream design day and age have left the core Delphi R&D team, maybe one of them can step in and explain why.


via: [WayBack] I was wondering if the TBufferedFileStream (see would not have been implemented using the decorator pattern… – Stefan Glienke – Google+ ->

TJclBufferedStream = class(TJclStreamDecorator)

2 Responses to “On the design of the Delphi TStream classes – why aren’t they decomposed better?”

  1. KMorwath said

    One of the reasons, IMHO, is that while TurboPascal streams were designed as a general I/O mechanism, when Delphi was designed they were tied too much to the form serialization task, losing the big picture. It was one of the (bad) surprise I had when I moved from TP7 to D1.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: