streaming redux

[Andrei Alexandrescu]

On 12/28/10 10:57 AM, SHOO wrote:
> (2010/12/28 16:02), 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!
>>
>>
>> Andrei
>
> I hope that this argument grows warm. For Phobos, the I/O is a very
> important component.
>
>
> I have some doubt about this interface.
>
> 1.
> There seems to be it on the basis of the deriving.
> In comparison with current std.stream, what will the advantage be?

With dynamically polymorphic interface, client code need not be 
templated in order to accommodate any implementation of the interface. 
Also, there is more opportunity for layering interface implemetations 
during run time.

This argument used to be stronger in e.g. C++ because defining a 
template function was noisier than defining a regular one. I'm glad to 
see that this particular problem is not as acute today in D.

> 2.
> I think that there are two advantages in I/O being introduced into
> Phobos _standard_ library. They are an advantage for a person defining a
> device and advantages for the user of the device.
>
> It gives a person defining I/O device an indicator to determine
> interface in a standard library. The person defining a device can apply
> to various helpers of Phobos by following this indicator. It just
> resembles relations of Range and Algorithms.
> In this case, it is important that a definition is simple.
> Range is very simple. It makes ends meet with only at least three
> definitions(front, popFront, empty). Like this, it is desirable for the
> base of the I/O interface to make ends meet with a minimum definition.
> However, TransportBase needs more definitions.
> Cannot you offer the interface that is simpler than in duck-typing?

I guess we can, but then let's not forget that to many people 
implementing interfaces is a well-learned lesson.

> On the other hand, an advantage of the users of the devices is to use
> unified interface and helpers, and it is the point that it can handle in
> the same way even if a device is anything.
> I think that at this point Input/OutputRange is good (like
> Unformatter/Formatter). Users can use various Algorithms by making it
> Range.

Right.

> 3.
> Formatter has writef, but thinks that this is unnecessary.
> Because the destination is binary data, writef to write in text data at
> should become the function of TextFormatter. And I can say a similar
> thing about readf of Unformatter.

Destination may be text or binary data.


Andrei