Accessors, byLine, input ranges

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> 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 :)

Which debate are you referring to?

> 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.

Yah, though I agree it's nicer to not prime the line in the constructor.


Andrei