So? I didn't say your way wouldn't work too.

Though it does require a distant, non-intuative (and unnecessary!) extra declaration of %test and %foo and %bar and %xxx for every other sub that has local subs--which is why I didn't go that route.

Your way buys me nothing, and requires extra.

Maybe you missed the fact that the first two of the messages you got were merely non-fatal warnings, and that all three of them did not happen until runtime. The message I got was compile time. Why are you using strict at all, if these arguments don't hold any weight with you?

If distant declarations bother you, use our.

#!/usr/bin/perl -l
use strict;
use warnings;

sub test{
    our %test;
    $test{localsub} = sub{
        print 'localsub1';
        return 12345;
    } unless exists $test{localsub};

    $tset{localsub}->();
}

print test;
__END__
Global symbol "%tset" requires explicit package name at t.pl line 12.
Execution of t.pl aborted due to compilation errors.
[download]

Update: I wrote our $test{localsub} = # ... at first, which is clearly wrong.

Makeshifts last the longest.

Also, that doesn't work.

#! perl -l
use strict;
use warnings;

sub test{
    our $test{localsub} = sub{
        print 'localsub1';
        return 12345;
    } unless exists $test{localsub};

    $test{localsub}->();
}

print test;
__END__
P:\test>junk
syntax error at P:\test\junk.pl line 6, near "$test{localsub"
Execution of P:\test\junk.pl aborted due to compilation errors.
[download]

It would have to become:

#! perl -l
use strict;
use warnings;

sub test{
    our %test;
    $test{localsub} = sub{
        print 'localsub1';
        return 12345;
    } unless exists $test{localsub};

    $test{localsub}->();
}

print test;
[download]

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

all three of them did not happen until runtime

The "only used once" warning from misspelling *tset occures at compile-time. If misspelled twice no warning is emitted though.

ihb

Read argumentation in its context!

No, I didn't miss it. I get a clear and accurate error message indicating where the problem lies the first time the sub is called and that is enough.

If I mis-type a method name, it is not detected until runtime.

If I invoke a sub through a coderef, it isn't detected until runtime.

Why should I be concerned about this particular warning -v- stricture?

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon