Re^6: goto &sub and local question

[TGI]

in reply to Re^5: goto &sub and local question
in thread goto &sub and local question

I like the idea of using one block, it's much cleaner. Thank you.

Whether you need to use a BEGIN around initializations in your main package really depends on how you write your code. If your initialization occurs in your script before you call any of the subs that rely on it, no BEGIN is needed. If you aren't initializing anything, no BEGIN is needed.

When you require or use a module, the code it contains is executed. So, any initializations will occur when the code is required, no matter where they are in the module. If the module is calls its own routines while being required, then the same possibility for problems with uninitialized block scoped variables exists.

# subs first - BEGIN not needed
{  my $var = 'blah';
   sub foo { ... }
   sub bar { ... }
}

sub bax { ... }

do_stuff_here();

# subs last - BEGIN needed iff initializing values.

do_stuff_here();  # $var has been created but not initialized. 

{  my $var = 'blah';
   sub foo { ... }
   sub bar { ... }
}

sub bax { ... }

When you say the BEGIN is probably not needed, I interpret your statement to mean that the BEGIN may not be necessary because the OP probably will not have to initialize his block scoped variables.

If my understanding is incorrect, is there some other mechanism that you suggest for initializing the variables?

[ikegami]

When you say the BEGIN is probably not needed, I interpret your statement to mean that the BEGIN may not be necessary because the OP probably will not have to initialize his block scoped variables.

Most code I've seen is organized such that initialization statements come before others. I meant BEGIN is probably not needed because the code is probably already executed in the right order without it.

If my understanding is incorrect, is there some other mechanism that you suggest for initializing the variables?

No, BEGIN is just fine. Like I said, even if it's not needed, there's no harm. For example, when I have an inlined module, I do

BEGIN {
   package ...;

   ...
}

The BEGIN is rarely needed there, but it has avoided problem in the past. There's no cost to adding the word BEGIN, especially since I already had curlies in place to limit the scope of package and any my and our vars.