IO#lineno= doesn't work the way I expected

On Mon, Nov 17, 2008 at 10:27:07PM +0900, Robert K. wrote:

There is no talk about read position in the file - just about “current
line number”. Also:

. . . which, to someone who isn’t assuming “line number” is just a
magical number plucked out of the air, makes it sound like it moves the
read position to a line whose ordinal position is that of the specified
line number. In other words, that’s how it “sounded” to me.

Yes, but the example makes it pretty clear that this is not the way it is:

Only if you didn’t read what I just said, and thus still think everyone
in the world made the same assumption you did.

The sample makes it very clear that the read position is not affected by
different content that would return “This is line two\n” when
explaining how lineno= works? The most obvious explanation is that
someone created a file where “This is line two” is actually placed in
the second line to demonstrate the non effect on file position.

If the point of the example was to demonstrate that, in order to get
“line two” of the output you want from line 1000 of the document, it
makes perfect sense. The most obvious explanation seems to me to be
the one that supports IO#lineno= actually being a needed method rather
than . . . whatever the hell it actually is.

I read it, initially, as meaning that
whatever line of the file it was, it just happened to say “This is line
two\n” because that made for some convenient text to have in the example.

Actually I believe the other interpretation is much more
straightforward and reasonable.

Clearly, you believe that. I believe reasonable people can come to
different conclusions about what that meant. In other words, I believe
it’s ambiguous. The fact you cannot imagine a different interpretation
than what immediately occurred to you is a failure of your imagination,
not mine. It seems to me that no matter how many times you look at it
you still cannot imagine how, with a different set of perfectly
reasonable starting assumptions, it means something different than you
initially thought it must mean is a result of confirmation bias rather
than a sign that I’m stupid – especially since, as I’ve pointed out, I
can understand where you got your interpretation and where I got mine.

Since the contents of the file were not made clear in advance, the
assumption that only the second line of the file can possibly say “This
is line two\n” does not clarify anything for the reader except by
accident. It could just mean “This is the second line of output from
this code.”

See above. IMHO only a bit application of common sense will show you
that your reasoning goes a bit astray here - although from a formal
point of view you are right.

In my humble opinion, an application of “common sense” yields different
results based on different reasonable starting assumptions, and that you
believe my reasoning has gone a bit astray only because you are
incapable
of understanding how someone can reasonably disagree with you about
initial assumptions.

You seem very invested in proving me “wrong” about the ambiguity of the
example. Do you feel insulted somehow because you wrote the example,
and
thus interpret what I’m saying as an attack?

ambiguous.

… for you.

Indeed. It’s not ambiguous for you because your initial assumption
turned out to be the same as that of the example’s author. It’s nice
how
that works for you.

I’m not the only person who thinks the example is ambiguous as written.
In fact, I’m not even the first person in this thread who said so. I
only said so when I realized how an alternate set of initial assumptions
led to the alternate interpretation to which you subscribe.

If you want a program that outputs “This is line one\nThis is
line two\n”, and for some reason lines 0 and 1000 of the file contain
“This is line one\n” and “This is line two\n” respectively, the alternate
interpretation of the way the method works makes perfect sense.

Formally speaking yes, with a bit of common sense, no.

There you go again. Apparently, “common sense” means “agrees with me”
in
your little world. Thus, when I disagree with you, I lack “common
sense”. I find that perspective somewhat limiting and egocentric, but I
guess it must reassure your self image somehow.

number of the next opened file.
Wouldn’t it be even more handy, in the general case, to be able to set
the offset in the file ahead a few hundred or thousand lines of text?
It
certainly would have been more handy for me, especially since there does
not appear to be any way at all to do so in Ruby from what I’ve seen
without actually reading those lines from the IO stream, whereas what
you’re talking about (implementing ARGF) is a one-time task that doesn’t
actually need the existing IO#lineno= method at all.

Chad, in your very long answer to Robert you forgot to quote the most
important part of his message:

On Mon, Nov 17, 2008 at 10:27:07PM +0900, Robert K. wrote:

Relax

2008/11/17 Chad P. [email protected]:

I believe reasonable people can come to
different conclusions about what that meant. In other words, I believe
it’s ambiguous.

Could you file a bug report on http://redmine.ruby-lang.org to make
the documentation less ambiguous to you? This way you’d help others,
who draw the same conclusions you did.

Wouldn’t it be even more handy, in the general case, to be able to set
the offset in the file ahead a few hundred or thousand lines of text? It
certainly would have been more handy for me, especially since there does
not appear to be any way at all to do so in Ruby from what I’ve seen
without actually reading those lines from the IO stream (…)

Such a method could be handy, indeed, but it would have to do the
same: actually read all those lines from the IO. There’s no other way
to do it.

Regards,
Pit