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

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]> wrote:
>=20
> >>The class is specced here, with the screen scrolled to where IO#lineno
> >>and IO#lineno=3D are listed:
> >>
> >>   http://ruby-doc.org/core/classes/IO.html#M002289
> >>
> >The description of the method is somewhat ambiguous if you ask me.
>=20
> I don't think so.

The more I look at it, the more ambiguous it appears to be.


>=20
> >------------------------------------------------------------- IO#lineno=
=3D
> >     ios.lineno =3D integer    =3D> integer
> >------------------------------------------------------------------------
> >     Manually sets the current line number to the given value. +$.+ is
> >     updated only on the next read.
>=20
> There is no talk about read position in the file - just about "current=20
> line number".  Also:

=2E . . 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
> >        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
>=20
> The sample makes it very clear that the read position is not affected by=
=20
> lineno=3D because file reading obviously continues at the position where=
=20
> 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 that
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.  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.

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
> >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"
>=20
> Right (if by "you" you do not mean Tim, somehow part of the thread is=20
> 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.  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.

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 numbers.
What the hell is the point of that?  Please explain that to me.

--=20
Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ]
My first programming koan: If a lambda has the ability to access its
context, but there isn't any context to access -- is it still a closure?