Accessors, byLine, input ranges

[Michel Fortin]

On 2010-01-29 12:21:18 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Michel Fortin wrote:
>> Yeah, it's less likely to be a problem. But "less likely to be a 
>> problem" does still does not make things reliable. Something reliable 
>> works all the time, or it just doesn't work and tells you.
> 
> stream.front after stream.popFront works all the time and fetches a new 
> line off the stream. Like Steve said, you can't at the same time fetch 
> a line and leave it back in the stream.

The problem is that algorithms that depends on this will work with 
other ranges, but will fail silently when given a stream.

In all seriousness, even Java streams are better modeled than this 
(although more limited by not having templates). The basic Java input 
stream doesn't have a 'front' byte, you can only read the next byte (or 
the few next bytes). If you need to rewind, there is a standard way, 
but most streams need to be wrapped in a buffered stream first to 
provide this capability.

So in our case, if you need to add a one-byte or a one-line buffer for 
a filtering stream I think it should be done explicitly as it has side 
effects on the underlying stream. In Java you do this by composition, 
creating a buffered stream from another input stream when you need one. 
Doing this implicitly, and especially creating a separate buffer each 
time you create a new filtering range, is what makes the problem hard 
to follow. Making 'front' lazy fetching will help in many cases, but 
it'll never remove the problem entirely.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/