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
