buffered input

[Andrei Alexandrescu]

On 2/6/11 10:37 PM, Robert Jacques wrote:
> On Sun, 06 Feb 2011 21:53:01 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 2/6/11 8:57 PM, Robert Jacques wrote:
>>> On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at 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