On 2/6/11 10:37 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 21:53:01 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 2/6/11 8:57 PM, Robert Jacques wrote:
On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 2/6/11 6:01 EST, Tomek Sowiński wrote:
Nick Sabalausky napisał:
discard and fetch?
I like that.
What's missing is the part that they refer to front. Maybe
discardFromFront() and fetchToFront()? But then I like
discardFromFront() and appendToFront() better - the latter is about as
long and more informative.
Don't forget that these are relatively rarely used.
Andrei
Actually, I don't think these functions would be relatively rarely used.
I don't see that many people using a buffered input's popFront. Instead
I see shiftFront in its place and an appendToFront call has to be made
whenever buffer.front.empty.
Both byLine and byChunk are buffered inputs, are often used, and will
have seldom use for the added functions.
Andrei
Yes, but byLine is a higher order meta-range designed primarily for end
users. I believe that internally, byLine would use
shiftFront/appendToFront, as would virtually all library code. I do
apologize for thinking only as a library writer, but you need to
remember those of us writing the JSON, XML, separated value, etc parsers
too, when designing the api.
I understand. Ultimately such widely used parsers would be themselves
encapsulated in library (Phobos?) modules. The general idea is that
straight reading tasks only need very simple code, and more
sophisticated reading tasks would need to use a couple more primitives.
That's not that bad, is it?
Andrei
