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


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

Yes. Next question.
Next question: why?
Seriously, what's wrong with a much easier approach like this?

Somebody could mess with the package global $FOO_HAS_BEEN_CALLED and blow things up, and call_me_only_once() gets called twice. Of course, call_me_once() disposing of itself properly after being called would make damn sure it isn't a second time :-)

--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}

Replies are listed 'Best First'.
Re^3: Is modifying the symbol table to redefine subroutines evil?
by perrin (Chancellor) on Apr 11, 2007 at 23:03 UTC
    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.

      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.
      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}
        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.

Re^3: Is modifying the symbol table to redefine subroutines evil?
by ikegami (Patriarch) on Apr 12, 2007 at 01:42 UTC
    Actually, there's no reason for it to be a package variable. I would have used a lexical. And bah! If someone shoots themselves in the foot by messing with internal state variables, it's their own foot. It's not like someone could accidently change the value of the variable.