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


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

Still no:

BEGIN { &Internals::SvREADONLY(\undef, 0); ${ \undef } = 42; &Internals::SvREADONLY(\undef, 1); } my $x = undef; print( ((undef) ? 'True' : 'False'), $/); print( ((defined undef) ? 'True' : 'False'), $/); print( (($x) ? 'True' : 'False'), $/); print( ((defined $x) ? 'True' : 'False'), $/); print $x; __OUTPUT__ True True False False

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re^4: The Null Mull (or, when OO needs more O)
by diotalevi (Canon) on Nov 29, 2004 at 22:07 UTC
    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.
      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.