Paul Driver > Monkey-Patch > Monkey::Patch

Download:
Monkey-Patch-0.03.tar.gz

Dependencies

Annotate this POD

CPAN RT

Open  0
View/Report Bugs
Module Version: 0.03   Source  

NAME ^

Monkey::Patch - Scoped monkeypatching (you can at least play nice)

VERSION ^

version 0.03

SYNOPSIS ^

    use Monkey::Patch qw(:all);

    sub some_subroutine {
        my $pkg = patch_class 'Some::Class' => 'something' => sub {
            my $original = shift;
            say "Whee!";
            $original->(@_);
        };
        Some::Class->something(); # says Whee! and does whatever
        undef $pkg;
        Some::Class->something(); # no longer says Whee! 

        my $obj = Some::Class->new;
        my $obj2 = Some::Class->new;

        my $whoah = patch_object $obj, 'twiddle' => sub {
            my $original = shift;
            my $self     = shift;
            say "Whoah!";
            $self->$original(@_);
        };

        $obj->twiddle();  # says Whoah!
        $obj2->twiddle(); # doesn't
        $obj->twiddle()   # still does
        undef $whoah;
        $obj->twiddle();  # but not any more

SUBROUTINES ^

The following subroutines are available (either individually or via :all)

patch_package (package, subname, code)

Wraps package's subroutine named <subname> with your <code>. Your code recieves the original subroutine as its first argument, followed by any arguments the subroutine would have normally gotten. You can always call the subroutine ref your received; if there was no subroutine by that name, the coderef will simply do nothing.

patch_class (class, methodname, code)

Just like patch_package, except that the @ISA chain is walked when you try to call the original subroutine if there wasn't any subroutine by that name in the package.

patch_object (object, methodname, code)

Just like patch_class, except that your code will only get called on the object you pass, not the entire class.

HANDLES ^

All the patch functions return a handle object. As soon as you lose the value of the handle (by calling in void context, assigning over the variable, undeffing the variable, letting it go out of scope, etc), the monkey patch is unwrapped. You can stack monkeypatches and let go of the handles in any order; they obey a stack discipline, and the most recent valid monkeypatch will always be called. Calling the "original" argument to your wrapper routine will always call the next-most-recent monkeypatched version (or, the original subroutine, of course).

BUGS ^

This magic is only faintly black, but mucking around with the symbol table is not for the faint of heart. Help make this module better by reporting any strange behavior that you see!

syntax highlighting: