in reply to Re: Signals and 'IGNORE'
in thread Signals and 'IGNORE'

or maybe [for self-documentation - thanks to broquaint for asking] 
{
    undef local $SIG{INT};
}

[download]
will do.
Yuck. Please don't advice people to write this kind of junk. Rather, teach them about Perl's default behaviour: if you localize a scalar variable, it gets the value undef — unless you assign something to it. So 
    local $foo;

[download]
should be self-documenting enough. (If it isn't: learn Perl!) But not this... perversion.

Replies are listed 'Best First'.
Re: Horrible "undef local $foo;" (was: Re: Signals and 'IGNORE')
by shotgunefx (Parson) on Jan 06, 2003 at 13:50 UTC
    Did you not read the part "or maybe [for self-documentation -"?

    undef local $SIG{INT} is clearer in intention than local $SIG{INT}. Reading other's code I might question if it was a piece of kruft (lavaflow, whatever there calling it now)

    -Lee

    "To be civilized is to deny one's nature."
[reply]
      undef local $SIG{INT} is clearer in intention than local $SIG{INT}.
      Not to me it isn't. It's actually more confusing. It immediately begs the question for me: "how come this coder doesn't know that all new variables are automatically born undef?". And then it has me question the quality of the remaining code. Or even question my own knowledge, wondering, "well, maybe there is a time when I need to undef that new variable explicitly that I don't know about". It's raising more questions than it's answering.

      Put another way, you do look funny when you wear both belt and suspenders, even though you make think you're just being safer or clearer about intent. Makes me wonder whether you're wearing both boxers and briefs as well.

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

[reply]
        Depends on who else you expect to read your code after. I think it's safe to say that Zaxo knows that local variables automatically are set to undef. Which I assume is exactly why he noted it as such. I would hardly call it "junk". It works and causes 0 problems with the code. It's a stylistic decision.

        I'll refrain from commenting on what I suspect you're wearing for undergarments.

        -Lee

        "To be civilized is to deny one's nature."
[reply]
        To me:
        # undef to restore SIGINT to normal behavior
undef local $SIG{INT};

        [download]
        And 
        # undef to restore SIGINT to normal behavior
local $SIG{INT};

        [download]
        Read the same, the cake is in the comment that reminds whoever is looking at the code what is trying to be accomplished.

        -Waswas
[reply]
[d/l]
[select]
      undef local $SIG{INT} is clearer in intention than local $SIG{INT}
      Allow me to disagree. I do not find it more readable, instead, I find this may qualify as obfuscation. This is not Perl. Well actually, it is, but I don't think it is normal Perl.

      If you insist on explicitely showing that this value is set to undef, please use a more common idiom: 

         local $SIG{INT} = undef;

      [download]
      The explicit assignment is still unnecessary, but at least it looks more harmless.
[reply]
[d/l]
        Personally, if I wanted to undef something and I was afraid it wouldn't be clear, I'd just use a comment... 
         # Temporarily undef the INT signal handler
 local $SIG{INT};

        [download]
        or such. But depending on who else is working on the code or the background, I do think that 
        undef local $foo
        can be clearer sans comment.

        What I really took issue with is what I perceived as your tone towards the poster. There's been a bit of what I consider, undue rudness at the Monestary as of late. Electronic communication mediums are not always the best for deriving the "intonation" of a message and perhaps I misread the tone of your comment. Regardless, I don't think the example was a wrong answer just a differently right one.

        -Lee

        "To be civilized is to deny one's nature."
[reply]
[d/l]

In Section Seekers of Perl Wisdom