in reply to Re^4: wanting to make a file of strings usable by SQL
in thread wanting to make a file of strings usable by SQL

Rule of thumb: eof is about as meritorious as goto.

In a word. Balderdash :)

$. Is that the commercial arm of /.?

Quite how you can claim that a comparison using eof is less clear than one using $. is quite beyond me.

Most anyone who has programmed in any C-like language, and a whole host of others, will immediately recognise the concept and purpose of the function eof.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^6: wanting to make a file of strings usable by SQL
by Aristotle (Chancellor) on Dec 27, 2005 at 07:13 UTC

    And yet, look at your code. Does that look readable to you? Honestly?

    There’s someone more prominent than me who said that function is almost always a bad choice. Because it is. The idea of eof is that you’re peeking ahead in the stream to see what will happen next. It is not at all comparable to testing $. in that sense.

    Makeshifts last the longest.

[reply]

      I ++ your version because I prefer it to mine. But...

      It is not at all comparable to testing $. in that sense.

      Of course it is.

      The result of the expression, $. == 0, is a flag who's only purpose is to detect the end-of-file condition. This is the express and only purpose of eof.

      The difference is that eof can operate on a named filehandle whereas, $. is global and can be reset by a read operation on any filehandle. Call a function from within the loop that accesses a totally different filehandle and you completely screw the loop. This is not true for eof.

      There’s someone more prominent than me who said that function is almost always a bad choice.

      If you read the context of the link you gave, you'll see that it's author is saying that it is unnecessary to explicitly test eof in order to terminate a read loop, because

      Perl returns an unambiguous end-of-file condition by yielding an undefined value. ... The while(<FH>) construction even does so automatically.

      Which is an entirely different context to the one under discussion.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

        The result of the expression, $. == 0, is a flag who's only purpose is to detect the end-of-file condition. This is the express and only purpose of eof.

        $. == 0 tests whether I’m looking at the first line, which, in my reality, is not exactly the same as testing for end-of-file…

        Update: err, almost. In my reality, $. == 0 is a bug and nothing but a bug. It was supposed to be $. == 1 of course. Quite how I missed that even though I actually tested the code, I don’t know.

        it's author is saying that it is unnecessary to explicitly test eof in order to terminate a read loop, [… w]hich is an entirely different context to the one under discussion.

        So the last if eof(DATA); line in your code is not a test to prematurely terminate the loop?

        Are we discussing some alternate universe? :-)

        Makeshifts last the longest.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom