in reply to Re^2: Is modifying the symbol table to redefine subroutines evil?
in thread Is modifying the symbol table to redefine subroutines evil?

Why? Because it solves a simple problem in a complex and convoluted way.

Somebody could mess with the package global $FOO_HAS_BEEN_CALLED and blow things up

The "somebody could mess with it" argument has never been valid for Perl. Of course somebody could mess with it! Somebody could mess with absolutely everything in your program. If you want to prevent possible accidental changes, you could make it a lexical instead and let foo() be a closure around it. But no one mentioned security as the reason for this.

I still think it sounds like setup code that should be in some kind of BEGIN or INIT block.

  • Comment on Re^3: Is modifying the symbol table to redefine subroutines evil?

Replies are listed 'Best First'.
Re^4: Is modifying the symbol table to redefine subroutines evil?
by bart (Canon) on Apr 12, 2007 at 18:04 UTC
    Of course somebody could mess with it! Somebody could mess with absolutely everything in your program.
    Agreed. "Somebody" could even be messing with the symbol table entry of *foo, in which case the assumed protection of it, is completely bogus.
[reply]
[d/l]
Re^4: Is modifying the symbol table to redefine subroutines evil?
by shmem (Chancellor) on Apr 12, 2007 at 05:29 UTC
    Because it solves a simple problem in a complex and convoluted way.

    I fail to see how re-arranging a single type glob entry is more convoluted (or complex) than having a state variable sitting around which is changed only once and tested every time the sub is called. The latter seems more like useless clutter to me.

    One problem with assigning an anonsub to a typeglob is that it will be reported as anonsub by confess and friends.

    But it's clear, concise code, its intent is clear. It might be extravagant or even bizarre, but not evil in the sense of utterly bad practice.

    --shmem 

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]
      I fail to see how re-arranging a single type glob entry is more convoluted (or complex) than having a state variable sitting around which is changed only once and tested every time the sub is called.

      Seriously? Using the variable is very simple, and the intent should be pretty obvious to anyone if the variable has a clear name. To me, it seems a lot less complex than a self-modifying program. The typeglob approach should at least have a comment explaining its purpose.

[reply]
        To me, it seems a lot less complex than a self-modifying program.

        Oh wait... self-modifying? In what sense? All the code there is, is there in the first place. As with the OP's code, we are talking of a named sub, whose code reference is replaced by an anonymous subroutine at the first call of that named sub. The code block for that anonymous subroutine reference is inside the named sub, and it is called at the first call of that named sub, and at all calls of that sub thereafter.

        No code is generated, and no code is modified at runtime. There's a conditional that is optimized away, not by the perl interpreter but explicitly by the programmer.

        If we would label that coding as writing a self-modifying program, then using e.g. POSIX would also comprise writing a self-modifying program - and all programs that use the AutoLoader, and all programs that pull in any module via use, require or do file.

        --shmem 

        _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]

In Section Seekers of Perl Wisdom