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


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

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.

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

[reply]

      yes, they are also globaller-than-global globals. you can see then in perlapi.h look for "pl_sv_". you don't ever overload them. you break everyone else's code when you change these values. in fact, this entire avenue is just off limits because you can't change the behaviour of undef, yes, and no without changing it for every piece of every module loaded, everywhere.

      the only case where you could possibly, maybe, change these values would be during small, discrete sections of your own code where you overload your value on entering and remove the overload before calling any functions, magic or explict, and before exiting. you'd have to have vetted all your input values to know that nothing has been tied, overloaded, or somehow has get or set magic. The point to this paranoia is that the none of the code you've included from cpan or from the core distribution is going to expect that true, false, and undefined have changed. It will break all other code that depends on them.

[reply]
        I understand that overloading them is asking for trouble. I want to know how to ask for trouble, if doing that is what I want to do. Of course, one shouldn't do this in production. However, it may be appropriate to do it in some really weird circumstance. Knowing how to do it is only half the battle - knowing when not to do it is the other half.

        So, how do you do it? :-)

        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.

[reply]

In Section Meditations