streaming redux

[Andrei Alexandrescu]

On 12/28/10 4:06 PM, Jonathan M Davis wrote:
> On Monday 27 December 2010 23:02:29 Andrei Alexandrescu wrote:
>> I've put together over the past days an embryonic streaming interface.
>> It separates transport from formatting, input from output, and buffered
>> from unbuffered operation.
>>
>> http://erdani.com/d/phobos/std_stream2.html
>>
>> There are a number of questions interspersed. It would be great to start
>> a discussion using that design as a baseline. Please voice any related
>> thoughts - thanks!
>
> The fact that streams here are interfaces and yet Phobos uses templates most
> everywhere rather than interfaces makes me wonder about what exactly the reasons
> for that are and what the pros and cons and both approaches really are. My first
> reaction at this point tends to be that if it's an interface, it can be a
> template, but that doesn't work as well if it's expected that it'll be normal
> for streams to be fed to virtual functions.

Dynamic polymorphism is a well understood style of coding and is 
somewhat simpler syntactically even in D. Conventional wisdom has it 
that one should use dynamic polymorphism if possible and resort to 
static polymorphism when considerations of e.g. type information or 
efficiency require it.

A statically polymorphic design of streams would define various 
Formatter structs parameterized on the type of transport, all offering 
the same implicit interface. Then, code that wants to use formatters 
would be parameterized by the type of the formatter. In fact this is 
what std.format does today.

> In any case, the one thing about this which immediately concerned me was the
> fact that TransportBase throws on some functions if the class implementing the
> interface doesn't support them. I _hate_ the fact that Java does that on some of
> their stream functions, and I'd hate to see that in D, let alone in Phobos. If
> it doesn't support them, _then it doesn't properly implement the interface_. How
> would you use such functions in real code? If you rely on their behavior, you're
> going to get an exception at runtime rather than being able to determine at
> compile time that that behavior isn't supported. And if you try to use them and
> they aren't supported, but you _can_ do what you need to do without them, then
> you have to catch an exception and then having a different code path.

I think that's a minor concern. Some files are seekable and some aren't. 
We're well used to that. This file passed to is seekable:

prog <foo.txt

This is not:

cat foo.txt | prog

It's a dynamically decided capability as cut and dried as it gets.

> I'd _strongly_ suggest splitting TransportBase into two interfaces if it has
> functions which aren't necessarily really implemented in the classes that
> implement it. And if for some reason, that isn't reasonable, at least add a
> function which is supposed to return whether the positioning primitives are
> properly implemented.

I think the latter is doable.


Andrei