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

On Mon, Nov 17, 2008 at 10:27:07PM +0900, Robert Klemme wrote:
> 2008/11/16 Chad Perrin <[e-mail]>:
> > On Sun, Nov 16, 2008 at 08:36:50PM +0900, Robert Klemme wrote:
> >> On 15.11.2008 20:51, Michael Guterl wrote:
> >> >On Sat, Nov 15, 2008 at 2:08 PM, Chad Perrin <[e-mail]> wr=
ote:
>=20
> >> >------------------------------------------------------------- IO#line=
no=3D
> >> >     ios.lineno =3D integer    =3D> integer
> >> >---------------------------------------------------------------------=
---
> >> >     Manually sets the current line number to the given value. +$.+ is
> >> >     updated only on the next read.
> >>
> >> 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.
>=20
> 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.


>=20
> >> >        f =3D File.new("testfile")
> >> >        f.gets                     #=3D> "This is line one\n"
> >> >        $.                         #=3D> 1
> >> >        f.lineno =3D 1000
> >> >        f.lineno                   #=3D> 1000
> >> >        $. # lineno of last read   #=3D> 1
> >> >        f.gets                     #=3D> "This is line two\n"
> >> >        $. # lineno of last read   #=3D> 1001
> >>
> >> The sample makes it very clear that the read position is not affected =
by
> >> lineno=3D because file reading obviously continues at the position whe=
re
> >> it was before.
> >
> > It only makes that clear if you assume a lot of things about what's in
> > the file in question.  I can see now, in retrospect, how you came to th=
at
> > conclusion -- but the fact that the second use of `f.gets` returns "This
> > is line two\n" doesn't *necessarily* mean that the return value is from
> > the second line of the file.
>=20
> Of course not.  But what sense would it make to create a file with a
> different content that would return "This is line two\n" when
> explaining how lineno=3D 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=3D actually being a needed method rather
than . . . whatever the hell it actually is.


>=20
> >  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 exampl=
e.
>=20
> 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.


>=20
> > 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."
>=20
> 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?


>=20
> >> >I would think if it had the behavior you described, the second time
> >> >f.gets is called, we would see: "This is line one thousand and one\n"
> >> >not "This is line two\n"
> >>
> >> Right (if by "you" you do not mean Tim, somehow part of the thread is
> >> missing in Usenet).
> >
> > I don't see why everyone has to assume that the second line of the file
> > necessarily contains the text "This is line two\n".  It's really very
> > ambiguous.
>=20
> ... 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.


>=20
> > 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 alterna=
te
> > interpretation of the way the method works makes *perfect* sense.
>=20
> 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.


>=20
> > What *doesn't* make any sense to me is the idea that, for some reason,
> > it's important and common enough an operation to misnumber line numbers
> > that there has to be a `lineno=3D` method that counterfeits line number=
s.
> > What the hell is the point of that?  Please explain that to me.
>=20
> I do not know this.  IO#lineno=3D can help implementing ARGF although it
> is not needed.  Maybe ARGF is completely implemented in Ruby and
> delegates to C code for the IO handling - including line counting. In
> that case it's handy to have this setter so you can offset the line
> 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=3D method at all.

--=20
Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ]
Quoth H. L. Mencken: "Democracy is the theory that the common people
know what they want and deserve to get it good and hard."