I always assume that subroutines will be put into a scope
where they will be compiled and never run [ that is,
the subroutine will probably be called, but the
lines around the subroutine will never be run ].
If you don't use the BEGIN, then you have a race condition
because the subroutine exists and can be called as soon as
it is compiled but its "static variable" (will be declared
but) won't be initialized until that line gets run,
which could happen much later or not at all.
I first ran into this problem with some border cases of
using modules. The one that I remember was having two
modules that depend on each other. Perl actually manages
to get this mostly right (doing better than I would have
thought was even possible). But the effect is that if A.pm
uses B.pm which uses A.pm, then either A::import() or
B::import() will be called before the code for that module
gets run. I recall finding another case that was less easy
to justify ignoring, but I don't remember the specifics
right now.
Another case is self-inflicted. I hate having to read
"between" a huge list of subroutine declarations looking
for the run-time statements so I force my top-level run-time
code into sub main and enforce this discipline
by ending my global declarations with:
exit( main( @ARGV ) );
(see (tye)Re: Stupid question for other self-inflicted discipline).
So I guess that boils down to "No, I don't have any glaring,
screaming, obvious cases that make not doing this a really,
really bad idea." (: It is a personal coding habit that
has saved me time more than once. It avoids a race
condition, which is usually a good thing.
-
tye
(but my friends call me "Tye") | 