[fpc-devel] A suggestion about streams

[Michael Van Canneyt]

On Fri, 30 Jun 2006, Sergei Gorelkin wrote:

> On Friday, June 30, 2006, 6:46:48 PM, Michael Van Canneyt wrote:
> 
> MVC> There is a difference for the implementor of streams:
> MVC> By keeping the method abstract, you FORCE the implementation of a method
> MVC> in a descendent.
> 
> MVC> The compiler will warn you if you try to instantiate a class which has an
> MVC> abstract method. If you implement the base method as virtual method, you
> MVC> will lose this warning, but you will not be aware that you have forgotten
> MVC> to override a method.
> 
> This is, of course, right. But is it important in particular case
> of TStream? Stream implementors basically have to implement only 3-4
> methods, so it's rather hard to forget to override a method. And even if
> one does forget, that will pop out on the first run.
> 
> The majority of FCL streams (encrypting, compressing, buffering, pipes,
> etc) are unidirectional, and only few (handle/file and memory) allow
> both reading and writing. Calling an invalid method (e.g. Read for
> write-only stream) is typically a programmer's (not user's) error and
> should never happen in a well written program. For this reason, IMO,
> keeping a separate handler and error message for each unidirectional
> stream merely increases the program size.

Hm. Yes. You can supply a patch, if you want. But then a patch which fixes 
all streams...

Michael.