Accessors, byLine, input ranges

[Steven Schveighoffer]

On Fri, 29 Jan 2010 08:03:13 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-01-29 06:25:44 -0500, Pelle Månsson <pelle.mansson at gmail.com>  
> said:
>
>> On 01/29/2010 05:48 AM, Michel Fortin wrote:
>>>  No. Calling byLine doesn't change the stream. It returns a different
>>> view of stdin, which can be used to modify the stream, or not. I think
>>> it should be a property. If it was 'getNextLine' then it should be a
>>> function. As a proof, this doesn't have any effect:
>>>  stdin.byLine;
>>  It reads a line off stdin. Try it.
>
> Ah, I see, you're right. Silly me for not trying.
>
> So it's not an accessor after all. The problem is that, even  
> disregarding the property syntax, the name strongly suggests it's an  
> accessor, but it has side effects, which it shouldn't. Either we change  
> the name to something else, like 'consumeLines()', or we make it behave  
> like an accessor. I'd go for the second option.
>
> The basic problem lies in the very basic definition of an input range.  
> Due to its interface (popFront + front), an input range is forced to  
> consume the its first element by its mere existence. I think  
> constructing an input range shouldn't have side effects. It should be  
> more symmetrical with an output range. It could have just one function,  
> 'take' to get the next element, and now byLine could work correctly.

Hey, it's that dead horse again, let's beat it!

Andrei and I and several others discussed this ad infinitum.  You will  
never convince Andrei that his design is wrong :)

The truth is, the fact that byLine modifies stdin by its mere existence  
proves to be inconsequential.  Nobody will fetch the byLine property  
without using it.  It's still an accessor.

-Steve