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

Ugh. That is definitely much less clear than his sed script. Without knowing what it’s supposed to do it’ll take blinking and staring to figure it out.

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

Makeshifts last the longest.

  • Comment on Re^4: wanting to make a file of strings usable by SQL

Replies are listed 'Best First'.
Re^5: wanting to make a file of strings usable by SQL
by BrowserUk (Patriarch) on Dec 27, 2005 at 05:03 UTC
    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.

      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.

        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.