On Fri, 29 Jan 2010 09:34:25 -0500, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
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 :)
Andrei is the one who complained that it's difficult to know whether
'byLine' is a property in the first place. I'm just explaining why it
is, and what should be done.
I agree.
I'm starting to think Anrei likes ambiguous semantics. :-)
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.
That's only true if you use byLine exclusively.
Here is a case where the advance fetching of byLine could go wrong:
// fetch 3 lines:
string[] consume(3, stdin.byLine);
// now fill a buffer
ubyte[] buffer;
buffer = stdin.rawRead(buffer);
E[] consume(E, R)(int count, R range) {
E[] elements;
foreach (i; 0..count) {
elements ~= range.front;
range.popFront();
}
return elements;
}
The problem here is that the consume() function will in reality consume
4 lines of stdin, even though it just take 3 from byLine.
When we later call rawRead, a line has been lost.
Yeah, I am on your side. byLine has some nuances that make it
incompatible with other uses of the stream. In fact, byLine might only be
useful in processing the entire file. Hm... opApply?
-Steve
