in reply to Re: Re: dumb question
in thread post-increment and post-decrement behavior (was: dumb question)

No, that is not correct. Perl still "printed" the undef value as an empty string, it did not abort the print function just because a value was undefined. You could see this with e.g. 
print $a--, "foo";

[download]
to see that you get both the warning and that "foo" is printed. But since printing an empty string is the same as not printing anything, it doesn't make much sense to argue this too long. :)

Replies are listed 'Best First'.
Re: Re: Re: Re: dumb question
by pg (Canon) on Mar 16, 2003 at 06:30 UTC
    Okay this is my last post in this thread. ;-)

    From a pure logic point of view, answer yourself this questions (if you don't oppose, only whisper the answer to yourself, so we come to an end of this thread ;-), but any way, this is my last post, as I don't believe any more value can be yielded, I expressed whatever I think right, and so did you ;-) My question:

    When your example looks agree with your conclusion that $a is printed as empty string, WHAT MAKES YOU THINK IT DOES NOT AGREE WITH MY CONCLUSION THAT $a IS SIMPLY IGNORED, AND A WARNING IS PRINTED?
[reply]
      WHAT MAKES YOU THINK IT DOES NOT AGREE WITH MY CONCLUSION THAT $a IS SIMPLY IGNORED, AND A WARNING IS PRINTED?
      Well, we can rely on the declared principle that warnings do not change anything about the execution of the program. Other than additional output to STDERR (and in the absence of a $SIG{__WARN__}, which this program clearly does not have), a program will always run identically whether warnings are on or off. Warnings do not change program execution flow. They merely turn on additional debugging output.

      Second, we can test whether print actually "printed" in two ways. First, it'll return a true value indicating a "successful" print to an open filehandle with no I/O error. Second, we can alter something like $\ to add additional text to the print. I'm sure if you do either of those, you'll see that the undef was treated as the empty string, a warning was sent to STDERR, and the print completed its task. The print was not aborted.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]
        Did I say that was my last post in the thread. (Hm... remember I had some little discussion with the other merlyn last time, but this merlyn is not that hot tempered one ;-)

        First I never said that print was aborted, instead I said "ignored". Also I never said what being ignored is the print statement as a whole, instead, what being ignored is that $a.

        Now afetr had a good sleep, I am now thinking this side tracked doscussion is meaningless (so what I am saying is that the discussion started by the thread owner is absolutely meaningful and interesting, but not this sub thread.)

        Why do I say this sub-thread is meaningless? Because, in fact, there is actually no way to distinguish the differences of the two concolusions by observation from outside, i.e. any example makes conclusion 1 sounds right, would also make conclusion 2 sounds right.

        Conclusion 1:

        print treats undef as empty string and issues a waring.

        Conclusion 2:

        print ignores undef, and issues a warning.

        We would realize that, those two conclusions are actually identical, if we are willing to put aside our eagerness to disapprove the other side.

        merlyn, I would be more interested in discuss with you/fight against you about the strength and weakness of POE and thread, see you.

[reply]
      It is ignored the same way as "" is ignored in: 
          print "";

      [download]
      Technically "" isn't being ignored, but the effect is as if it was ignored because this statement was a no-op to start with.
[reply]
[d/l]

In Section Seekers of Perl Wisdom