Short answer: no.
Long answer: perl doesn't know at compile time whether the typeglob CODE slot it allocates at
compile time will be actually filled with code at run time.
#!/usr/bin/perl
#
use warnings; use strict; use 5.008;
sub monk($) {}
sub go() { mink(123); }
BEGIN { print "$_\n" for grep { /^m/ } sort keys %main:: }
go();
__END__
main::
mink
monk
Undefined subroutine &main::mink called at sub.pl line 5.
Mentioning a subroutine somewhere in the code has (as far as typeglob allocation goes) a similar effect as subroutine forward declarations:
#!/usr/bin/perl
#
use warnings; use strict; use 5.008;
sub mink; # sub mink still undefined, but typeglob allocated.
sub monk($) {}
sub go() { mink(123); }
BEGIN { print "$_\n" for grep { /^m/ } sort keys %main:: }
go();
__END__
main::
mink
monk
Undefined subroutine &main::mink called at sub.pl line 6.
AFAIK there's no pragma which enforces allocating the code reference *) in the CODE slot along with
typeglob allocation.
*) Actually it is not just the code reference (which is what you get when you look into the CODE slot)
but something deeper in perl's data structures. That is why
use strict;
$SIG{CHLD} = \&mywait; # value in the %SIG hash is an empty code ref
compiles without problem, even if the sub mywait { } never gets defined, and the coderef therefor
is never populated with code proper.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
|