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

The subroutine changes its own definition. I'd certainly call that self-modifying. The exporter and friends just alias things into other namespaces.

I do use code that does things like this, mostly for accessor methods. Those don't have an obvious simpler alternative.

Replies are listed 'Best First'.
Re^8: Is modifying the symbol table to redefine subroutines evil?
by shmem (Chancellor) on Apr 12, 2007 at 21:35 UTC
    The subroutine changes its own definition. I'd certainly call that self-modifying.

    No, it doesn't. The subroutine's definition is what is inside the code block which gets assigned to the CODE typeglob entry of that named sub. The code reference is changed, nothing else. The rest is providing for something like an INIT block attached to a subroutine.

    That's not clear, at first glance, wich is the only objection I have to it. I wonder whether Perl 6 has some better semantics for that.

    update: using the AutoLoader, the OP's code could be rewritten in a foo.al:

    call_me_only_once(); sub foo { # the real foo() ... } 1;

    and we would all be happy autoloading foo and having call_me_only_once() be called just once.

    Would that be self-modifying code?

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