streaming redux

[SHOO]

(2010/12/29 15:01), Andrei Alexandrescu wrote:
>> 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.
>

I think interface is good for stream. Basically, handling of I/O is 
processing to take time very much. I think that I can ignore function 
call overhead, because it is very smaller than I/O processing.
Because inheritance has not a little advantageous, I do not have the 
dissenting opinion for inheritance.


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

There is not the problem even if it used interface if I can easily 
define a device.
Current Transport needs many definitions. For example, even if the 
device is impossible, it is necessary to consider seek. Because seek and 
buffering are options, I hope the interface that is not necessary to 
define and consider basically.

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

Is Formatter one of several interface for users of the devices? Or is 
Formatter aimed at replacing all the interface of the Range-based such 
as ByLine and ByChunk?
I think that you had better make different interface for the different 
thing.
For formatted text, I think that Formatter is useful. However, for the 
binary data, I think that another interface is necessary.