Steven Schveighoffer wrote:
On Fri, 29 Jan 2010 08:03:13 -0500, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2010-01-29 06:25:44 -0500, Pelle Månsson <pelle.mans...@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
