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 “stream16.zip” 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.
–jeroen
via: [WayBack] I was wondering if the TBufferedFileStream (see https://delphiaball.co.uk/2016/04/29/faster-filestream-tbufferedfilestream/) would not have been implemented using the decorator pattern… – Stefan Glienke – Google+ -> https://github.com/project-jedi/jcl/blob/master/jcl/source/common/JclStreams.pas#L207
TJclBufferedStream = class(TJclStreamDecorator)
https://gist.github.com/jpluimers/7a744a29f29556fab97fc4954db17d8f
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.
jpluimers said
I think you’re right. I’m still surprised.