Nod on the BEGIN{} issues. I'm just used to thinking of run-time versus compile-time overall, but the more correct way is to think of run-time and compile-time as a per-block thing. The outer begin block has its run-time at the script's compile-time. The inner begin block has its run-time at the compile-time of the outer begin block.

Big fleas have little fleas, upon their backs to bite 'em
Little fleas have lesser fleas, and so, ad infinitum.

but the more correct way is to think of run-time and compile-time as a per-block thing.

Quite so, ++ (Per-statement, even, in the case of use.)

print("first");
BEGIN {
  delete $INC{'ModX.pm'};
  use lib '../';
  use ModX;
}
print("last");
[download]

gets executed in the following order

use lib '../';           # Before "delete" because of "use"
use ModX;                # Before "delete" because of "use"
delete $INC{'ModX.pm'};  # Before "first" because of "BEGIN"
print("first");
print("last");
[download]

In detail:

1. Compile print("first");.
2. Compile BEGIN { ... }.
   1. Compile delete $INC{'ModX.pm'};.
   2. Compile use lib '../';.
   3. Execute use lib '../';.
   4. Compile use ModX;.
   5. Execute use ModX;.
3. Execute BEGIN { ... }.
   1. Execute delete $INC{'ModX.pm'};.
4. Compile print("last");.
5. "Run phase" starts.
6. Execute print("first");.
7. Execute print("last");.

but the more correct way is to think of run-time and compile-time as a per-block thing.

(Per-statement, even, in the case of use.)

More than just in the case of use. Certainly "my" statements have separate compile-time and run-time effects. "sub" declarations also have a compile-time impact as do "package" statements (as demonstrated in Object lesson). There may be others as well that just don't spring immediately to my mind.

See Re^5: What is the scope of BEGIN? Or... when does it "begin?" (steps). Each statement has one "compile time" and zero or more "run times". I never talk about the one "compile time" or the one "run time" as that makes no sense to me. I'd not say '"Run phase" starts', for example.

There is behavior that is triggered between when the main script source code has finished being compiled and the resulting non-sub code begins to be run. (Since I've never found a need to use CHECK / INIT blocks, I've never bothered to figure out and internalize how they are really scheduled, however.) But it makes no sense to me to say "CHECK code blocks are run [...] before run time begins" when lots of code has already seen its "run time" (and been run) before that.

- tye        

Sorry, that code snippet wasn't very clear... @foo is just the list of what you want to import.

But in the above code I wouldn't know at the time I was calling import.

However, I think I've got it nailed down in this node.

Basically, the import happens after all the messing about, so I don't need to do anything - the 'use' at the script level will call import after I've finished loading things.