What can we assume in a BEGIN block ?

leriksen has asked for the wisdom of the Perl Monks concerning the following question:

Brother Monks,

My question is 'what parts of your code can you assume have already been parsed when you are writing a BEGIN block ?'

I ask because I spent quite some time on the weekend struggling with a package global, set in a BEGIN block, getting clobbered at run time for reasons that are still a little unclear.

Background : I am refactoring some modules, one of which pulls in a configuration file at compile time. That is, clients of this module use it thus

...
use Config qw(getConfig);
...
my $foo = getConfig('bar');
...
[download]

In Config.pm, the code was originally like this

package Config;

my $initialised = 0;

sub _initialise {
    return if $initialised;
    ... # read config file
    $initialised++;
}

_initialise();

sub getConfig{...}
...
1;
[download]

This worked, but I changed the $initialised from a my to an our so that there was a way to reload a config file if required (I've changed this to a Reload() method now)

And because I wanted to make clearer that the call to _initialise() was a deliberate decision, I put it in a BEGIN {} block - to me it stands out a lot clearer that the bare statement in the original.

So we have

package Config;

our $initialised = 0;

sub _initialise {
    ... # as before
}

BEGIN {
    _initialise();
}
...
1;
[download]

Now because I like writing correct code, I wrapped all this in a test harness ala Test::More, and took advantage of the fact that $initialised was a package global to write a test like

...
use_ok('Config');
is($Config::initialised, 1); # initialisation completed OK
[download]

And guess what, I got

t/Config....Name "Config::var" used only once: possible typo at t/Conf
+ig.t line 9.
#     Failed test (t/Config.t at line 9)
#          got: '0'
#     expected: '1'
# Looks like you failed 1 tests of 2.
t/Config....dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 2
        Failed 1/2 tests, 50.00% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
----------------------------------------------------------------------
+---------
t/Config.t     1   256     2    1  50.00%  2
Failed 1/1 test scripts, 0.00% okay. 1/2 subtests failed, 50.00% okay.
make: *** [test_dynamic] Error 2
[download]

It looks like the initialisation never happened - but I know it happened because I sprinkled a lot of print's in _initialise() to see it working. So it looks like the our $initialised = 0; is clobbering the value set in the BEGIN, at run time. I hope I'm not using the terms compile/run time too loosely.

After pondering and playing for a while, I came up with this version that seems to be correct.

package Config;

sub _initialise {
    ... # as before
}

BEGIN {
    our $initialised = 0;

    _initialise();
}

1;
[download]

This works correctly (though I still get the warning about the var only used once), but the declaration of the our $initialised in the BEGIN looks weird. I suppose if you think about the BEGIN as getting run-time behaviour at compile time, it looks less weird, if you squint.

So if I can't rely on the our $initialised outside the BEGIN as 'existing' when the BEGIN runs, what are the rules about what is in scope before/during/after a BEGIN ?

use brain;

Comment on What can we assume in a BEGIN block ? Select or Download Code

Replies are listed 'Best First'.
Re: What can we assume in a BEGIN block ? by dave_the_m (Monsignor) on Oct 04, 2004 at 10:57 UTC
In the following, `$foo = 1; BEGIN { $foo = 2 }` [download] The BEGIN block is executed first, so $foo is first set to 2, and then to 1. On the other hand, `BEGIN { $foo = 1; $foo = 2 }` [download] $foo is set to 1 and then 2. Dave.	[reply] [d/l] [select]
Re^2: What can we assume in a BEGIN block ? by leriksen (Curate) on Oct 04, 2004 at 11:31 UTC
I suppose this just highlights my difficulty I 'expect' the opposite. `$foo = 1;` this has been parsed first, hasn't it ? So $foo == 1, right ? THEN the BEGIN is parsed, and so now $foo == 2, right ? use brain;	[reply] [d/l]
Re^3: What can we assume in a BEGIN block ? by hv (Prior) on Oct 04, 2004 at 12:03 UTC
The code under discussion is effectively this: `our $initialized = 0; BEGIN { $initialized = 1; } more stuff` [download] The significant information is that `our $variable = value` has both a compile-time and a runtime effect. When Perl parses the first line, it sees the variable declaration - the compile-time effect - and therefore knows how to interpret other references to this variable in the rest of the lexical scope (file scope in this case). It also sees the assignment, and compiles that to be executed at runtime (the runtime effect). When it parses the second line it sees the BEGIN block, so as soon as it has reached the end of the block it suspends parsing to execute the block. At this point the runtime assignment `$initialized = 0` has not yet happened. It then resumes parsing the file, and once the entire file has been compiled it then executes the top-level code. This is the point at which the variable gets set to zero. Hugo	[reply] [d/l] [select]
Re^4: What can we assume in a BEGIN block ? by leriksen (Curate) on Oct 04, 2004 at 12:36 UTC
•Re^5: What can we assume in a BEGIN block ? by merlyn (Sage) on Oct 04, 2004 at 12:52 UTC
Some notes below your chosen depth have not been shown here
Re^3: What can we assume in a BEGIN block ? by fergal (Chaplain) on Oct 04, 2004 at 12:56 UTC
I think you're reading `our $foo = 1; BEGIN {...}` [download] as: allocate some memory and initialise it to 1 and you expect it to happen at parse/compile time but you should think of it as just a shorthand for `our $foo; $foo = 1; BEGIN {...}` [download] so the memory is allocated at compile time but the initialisation happens at runtime, which will be after all the BEGIN blocks have run. It might seem like a good idea to initialise $foo to 1 at the same time as allocating the space but then you run into problems like `our $foo=sub_which_hasnt_been_compiled_yet();` [download]	[reply] [d/l] [select]
Re: What can we assume in a BEGIN block ? by TedPride (Priest) on Oct 04, 2004 at 10:02 UTC
"Normally, while parsing a file, Perl compiles the entire code, and when this process is successfully completed, it starts executing from the first global statement onward. However, if it encounters a subroutine or a block called BEGIN while parsing, it not only compiles it, but also executes it right away, before resuming the compilation of the rest of the file." So if I'm reading this right, everything inside the BEGIN block runs first, regardless of where the BEGIN block is located in the program.	[reply]
Re^2: What can we assume in a BEGIN block ? by herveus (Prior) on Oct 04, 2004 at 11:29 UTC
Howdy! That would be spot on! The call to _initialize occurs at compile time, but the initialization part of the "our" statement occurs at run time. yours, Michael	[reply]
Re^3: What can we assume in a BEGIN block ? by leriksen (Curate) on Oct 04, 2004 at 11:34 UTC
OK, so now I know I really dont get it. What variable got incremented at compile time ? If the "our $initialised" doesnt happen till run-time, what did we increment during the BEGIN? use brain;	[reply]
Re^4: What can we assume in a BEGIN block ? by diotalevi (Canon) on Oct 04, 2004 at 13:40 UTC
Re^2: What can we assume in a BEGIN block ? by leriksen (Curate) on Oct 04, 2004 at 11:27 UTC
OK, I may be focussing too closely here if it encounters a subroutine or a block called BEGIN while parsing... what happens to everything it has parsed upto the BEGIN block - does it forget about it till the begin has been completed. The doc says 'parsed' - does that mean entries in the symbol table etc have been made too ? use brain;	[reply]