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