I think that there are two problems about I/O operation.
- Location of buffering layers.
- Direction of seeking.
Other than these two problems, it is settled from requirements naturally.
Requirements are:
- Being easy to expand Handle.
For File, Socket, Pipe, Memory, VirtualFile, USB, Bluetooth,
SerialPort, and so on. Handle should be the interface that can
support them by minimum work. This means that Handle cannot have
optional functions such as byLine as required items.
- The handling should be simple for a user.
This is equal to supporting Ranges. General-purpose functions or
classes to generate Range are necessary to be able to treat Handle
easily.
It is necessary for the concept to be divided in two at least to realize
them. (Handles and Ranges) Or more(+ Port or Stream).
The opening difficult item appears when I think about this.
(2010/09/09 2:29), SHOO wrote:
Because it was gathered up about a past article by an argument about
Stream of the Japanese community, I introduce it.
This remark translated the summary of the remark of @s50 into English.
( Thanks s50! ( https://twitter.com/s50 ),
See also
http://dusers.dip.jp/modules/forum/index.php?topic_id=75#post_id291 in
Japanese article.)
The past arguments about the input/output are as follows:
*
http://lists.puremagic.com/pipermail/digitalmars-d/2008-October/043320.html
This remark shows a claim that Andrei abandons std.stream for the first
time.
At this stage, it is not planning to yet become ripe.
*
http://lists.puremagic.com/pipermail/digitalmars-d/2009-January/048184.html
Andrei shows a thought to abolish std.stream again here.
*
http://lists.puremagic.com/pipermail/digitalmars-d/2009-February/049385.html
Andrei awfully criticized std.stream.
He seem to have thought about the input/output that used Range in this time.
*** Process to reach getNext ***
The central figures are Andrei and Steven.
Andrei has a personal view in Range for I/O.
Steven is skeptical about Range, but agrees that developing of new
input/output.
* http://lists.puremagic.com/pipermail/digitalmars-d/2009-May/056773.html
The first opinion about popNext is shown.
* http://lists.puremagic.com/pipermail/digitalmars-d/2009-May/056859.html
It is the topic that Steve strongly recommends popNext.
* http://lists.puremagic.com/pipermail/digitalmars-d/2009-July/060404.html
popNext to getNext.
Andrei argued that "the simplest and most natural interface for a pure
input stream has only one function getNext which at the same time gets
the element and bumps the stream."
* http://lists.puremagic.com/pipermail/digitalmars-d/2010-March/073856.html
Again.
Related: [Issue 4025] New: Making network with the std.stdio.File interface
* http://lists.puremagic.com/pipermail/phobos/2010-March/000213.html
Adam's approach to std.file.File for socket.
The focus of this topic is reading of the variable-length data packet.
* http://lists.puremagic.com/pipermail/digitalmars-d/2010-July/079011.html
Andrei's opinion about getNext is shown here.
*** Ranges and Handles ***
Recent Andrei seems to think that Range(high level interface) and
Handle(primitive interface) should perform input/output.
(Just for the record, I agree this opinion.)
* http://lists.puremagic.com/pipermail/digitalmars-d/2009-May/056942.html
At first, His opinion says Ranges handle I/O instead of Streams.
* http://lists.puremagic.com/pipermail/phobos/2010-March/000106.html
He seems to think that Range should be offered by Handle recently.
* http://lists.puremagic.com/pipermail/phobos/2010-April/000272.html
Let's not forget that File isn't a range. Let's call it a "stream handle"
(I push *Steam*. Speaking of Range, it is Microwave, Oven and
Overheating-Steam! :-) )
* http://lists.puremagic.com/pipermail/digitalmars-d/2010-June/078675.html
"It's best to have a handle/ranges architecture in which the handle
(e.g. File) is responsible for opening, closing, and managing the
connection, and several ranges are responsible for fetching data in
various ways (by character, by chunk, by line etc.)"
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
