On Sat, Feb 12, 2005 at 11:30:56PM -0500, David A. Golden wrote:
> > stdout_is {
> > print scalar caller;
> > } scalar caller;
>
> That's a good warning on code blocks, and worth documenting for a module
> like this, but I'm not sure it's going to be a big issue in writing test
> scripts. Unless you're testing the "print" built-in function, that test
> is more easily written as
>
> is(scalar caller, scalar caller)
Carp. Stack traces. Testing functions. Error messages. Anything which
makes use of caller can have its results altered. The above was just the
simplest possible illustration of the problem. Here's a slightly more
pragmatic example.
#!/usr/bin/perl
use Carp;
sub test (&) { $_[0]->() }
sub foo { carp "In foo" }
#line 10
test { foo() };
#line 10
foo();
__END__
In foo at /Users/schwern/tmp/stack.plx line 7
main::foo() called at /Users/schwern/tmp/stack.plx line 10
main::__ANON__() called at /Users/schwern/tmp/stack.plx line 5
main::test('CODE(0x809f6c)') called at /Users/schwern/tmp/stack.plx
line 10
In foo at /Users/schwern/tmp/stack.plx line 7
main::foo() called at /Users/schwern/tmp/stack.plx line 10
The result of those two calls to foo() should be exactly the same, the
testing function should not interfere at all otherwise you have the test
altering the environment and adding another variable to testing a bug.
Its rare but when it happens it can cause hours of frustration when the
test is performing differently than the regular code.
The simplest way to avoid this is to use Sub::Uplevel. Or don't try to
force the (&) prototype into being a block. This is another reason I
prefer ->read().
