1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
NAME
Sub::Uplevel - apparently run a function in a higher stack frame
VERSION
This documentation describes version 0.22
SYNOPSIS
use Sub::Uplevel;
sub foo {
print join " - ", caller;
}
sub bar {
uplevel 1, \&foo;
}
#line 11
bar(); # main - foo.plx - 11
DESCRIPTION
Like Tcl's uplevel() function, but not quite so dangerous. The idea is
just to fool caller(). All the really naughty bits of Tcl's uplevel()
are avoided.
THIS IS NOT THE SORT OF THING YOU WANT TO DO EVERYDAY
uplevel
uplevel $num_frames, \&func, @args;
Makes the given function think it's being executed $num_frames
higher than the current stack level. So when they use
caller($frames) it will actually give caller($frames + $num_frames)
for them.
`uplevel(1, \&some_func, @_)' is effectively `goto &some_func' but
you don't immediately exit the current subroutine. So while you
can't do this:
sub wrapper {
print "Before\n";
goto &some_func;
print "After\n";
}
you can do this:
sub wrapper {
print "Before\n";
my @out = uplevel 1, &some_func;
print "After\n";
return @out;
}
`uplevel' will issue a warning if `$num_frames' is more than the
current call stack depth.
EXAMPLE
The main reason I wrote this module is so I could write wrappers around
functions and they wouldn't be aware they've been wrapped.
use Sub::Uplevel;
my $original_foo = \&foo;
*foo = sub {
my @output = uplevel 1, $original_foo;
print "foo() returned: @output";
return @output;
};
If this code frightens you you should not use this module.
BUGS and CAVEATS
Well, the bad news is uplevel() is about 5 times slower than a normal
function call. XS implementation anyone? It also slows down every
invocation of caller(), regardless of whether uplevel() is in effect.
Sub::Uplevel overrides CORE::GLOBAL::caller temporarily for the scope of
each uplevel call. It does its best to work with any previously existing
CORE::GLOBAL::caller (both when Sub::Uplevel is first loaded and within
each uplevel call) such as from Contextual::Return or Hook::LexWrap.
However, if you are routinely using multiple modules that override
CORE::GLOBAL::caller, you are probably asking for trouble.
You should load Sub::Uplevel as early as possible within your program.
As with all CORE::GLOBAL overloading, the overload will not affect
modules that have already been compiled prior to the overload. One
module that often is unavoidably loaded prior to Sub::Uplevel is
Exporter. To forceably recompile Exporter (and Exporter::Heavy) after
loading Sub::Uplevel, use it with the ":aggressive" tag:
use Sub::Uplevel qw/:aggressive/;
The private function `Sub::Uplevel::_force_reload()' may be passed a
list of additional modules to reload if ":aggressive" is not aggressive
enough. Reloading modules may break things, so only use this as a last
resort.
As of version 0.20, Sub::Uplevel requires Perl 5.6 or greater.
HISTORY
Those who do not learn from HISTORY are doomed to repeat it.
The lesson here is simple: Don't sit next to a Tcl programmer at the
dinner table.
THANKS
Thanks to Brent Welch, Damian Conway and Robin Houston.
AUTHORS
David A Golden <dagolden@cpan.org> (current maintainer)
Michael G Schwern <schwern@pobox.com> (original author)
LICENSE
Original code Copyright (c) 2001 to 2007 by Michael G Schwern.
Additional code Copyright (c) 2006 to 2008 by David A Golden.
This program is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
See http://www.perl.com/perl/misc/Artistic.html
SEE ALSO
PadWalker (for the similar idea with lexicals), Hook::LexWrap, Tcl's
uplevel() at http://www.scriptics.com/man/tcl8.4/TclCmd/uplevel.htm
|