On 14 Nov 2017, at 10:20, Prof. Andrew P. Black <black@cs.pdx.edu> wrote:
On 13 Nov 2017, at 20:27 , Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is a discussion about positioning (#position , #position: and related) but these cannot be supported _in general_ by the kind of streams described above.
I agree with that. But I think that general streams can, and should support:
# saveState âanswers an opaque cookieâ # restoreState: aCookieObtainedFromTheSameStream
This enables pone to read ahead, and then reset the state to the way that it was. The implementation of the cookie will depend on the implementation of the stream. In the simplest case it may be an integer position (sufficient for an in-core stream); in the more general case it may include a copy of the streamâs buffer, and the cookie obtained by saving the state of any wrapped stream.
Andrew
Yes and no: #saveState / #restoreState: need a possibly unlimited memory/buffer, similar to #position / #position: They cannot be offered in general (a socket stream is infinite, has no begin/end, in most cases). But I do think that a wrapper stream could add such feature, we only have to implement one and agree on the API (and the buffer size should probably be limited in size). I am curious though, why do you need it ? I mean, I got away (and try hard) to only use 1-element peeking and managed to implement STON, NeoJSON, NeoCSV, Stomp, PostgresSQL, Redis, and other protocols. A syntax that really requires multi element peeking is not so common. Sven