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.

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

Err, yes. I wrote that code in the browser, then pasted into a file to test, then corrected it in the file the way you did, but then failed to paste it back to the browser. D'oh.

Makeshifts last the longest.

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!

Oof. You are correct. You nitpick even better than me. Whether that is a compliment is your call. ;-)

Makeshifts last the longest.

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

That argument hinges on whether you believe that it would be undesirable to have compile-time checking for methods. If you agree that it would be desirable (I certainly would find it so), then the argument you are making is backwards. By that logic, you would choose to not have your method calls compile-time checked even if the option existed, because after all, coderefs can't be checked either, so who cares, right?

Makeshifts last the longest.