streaming redux

Jonathan M Davis jmdavisProg at gmx.com
Tue Dec 28 14:06:02 PST 2010


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.

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

- Jonathan M Davis


More information about the Digitalmars-d mailing list