http://www.perlmonks.org?node_id=411058


in reply to Re^3: The Null Mull (or, when OO needs more O)
in thread The Null Mull (or, when OO needs more O)

Aha. my $x = undef wasn't as simple as we thought. $x was being cleared without PL_undef actually being assigned. Swap the right side for something more complicated like $hash{'non-existant'} and you'll find that $x is now 42.

Replies are listed 'Best First'.
Re^5: The Null Mull (or, when OO needs more O)
by dragonchild (Archbishop) on Nov 30, 2004 at 13:35 UTC
    That's a pity ... I thought the undef function was supposed to return PL_undef if you passed it no parameters. At least, that's what the Perl cookbook implies on p369, as well as the Camel in its discussion of the undef function in the Appendices. Why wouldn't it work? (And, yes, I'm scared of spelunking the Perl codebase.)

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      A further look with B::Concise show that subsequent, simple assignments to $x also worked. It appears that because my $x is equivalent to my $x = undef, perl didn't bother actually writing the = undef part to the variable already guaranteed to be undef anyway. So its an optimization.

      I'd like to note that no one should ever actually attempt to overload undef in anything outside obfuscations. Since undef is a process wide global in way that even normal globals aren't global, you're propogating this new, defined value to every other module that's being used in your code. Now everything that used to return undefined to indicate failure will automatically signal success on failure, anyone using undef() as a parameter to select() for a sleep() will find themselves testing actual file handles. This is a seriously bad design decision that will warp the hell out of any process that uses it. Its cute for trying things like this out but no one should ever, ever, ever actually do this.

        Would PL_YES (!!1) and PL_NO (!!0) be similarly globaller-than-global globals? If so, how would one go about overriding them? Or, are we overriding the undef() function when we do the above-mentioned trick? If so, why aren't we using CORE::undef() instead of the internals trick?

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.