Erm, the BEGIN block is kind of central to the equivalent; it shouldn't be surprising that omitting it changes the sequence things happen. The CHECK and INIT phases have already passed by the time your runtime require executes. Similarly if you've got modules which are used their requires will be done during the compilation phase since by definition use executes then.

Try again - in the expectation that the Node Reaper might step in...

TFT Fletch - twas the very insight I was too close to see.

Having said that, does that imply that a run-time require goes thro' the phases anonymously - since as we know, eval { require ... } can be used to detect run-time problems ?

Update

Observation withdrawn in the light of further, Fletch originated insight - the key being initial - just goes to show that you only read what you want to c/w what's actually there.

A user level that continues to overstate my experience :-))

A BEGIN block will run because those run at compilation time and require drops Perl back into the compiler.

Likewise an END block will run because that phase hasn't yet occurred when the require is executing.

However CHECK, which runs (to quote perlmod) "after the initial Perl compile phase", and INIT blocks, which run "just before the Perl runtime begins execution", are not executed since their triggers (post-initial compile phase and prior to the runtime starting) have already passed. But when they're encountered during a BEGIN block by virtue of the code being pulled in via use those phases haven't passed and hence they will be called.

$ perl -MSpoo -e 0
Spoo BEGIN
Spoo CHECK
Spoo INIT
Spoo END
$ perl -e 'require Spoo'
Spoo BEGIN
Spoo END
$ cat Spoo.pm
package Spoo;

BEGIN { print "Spoo BEGIN\n"; }
END { print "Spoo END\n";  }
INIT { print "Spoo INIT\n"; }
CHECK { print "Spoo CHECK\n"; }

1;

__END__
[download]

Think of it this way: BEGIN and friends are kind of special event handler subs called by the Perl runtime. When the given event happens (compilation phase occurs, the runtime is about to start) the runtime looks into the module in question and if it has defined a handler for that event the runtime executes the corresponding sub. It's just that some of the events don't occur for require because they're one time only and that time's passed for the current execution.

Update: Slight pronoun and wording tweak in last paragraph.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Any road up, my problem now is the oft-quoted equivalent of the use statement, being approximated to...

BEGIN { 
    require module; 
    module->import(); 
}
[download]

...

Now, compare and contrast that with changing the script - to..

require Test1; 
Test1->method();
[download]

Consider the trivial example of module:

package Test1;
[download]

$ cat Foo.pm
use warnings;
CHECK { print "in check\n" }
INIT { print "in init\n" }
1;
$ perl -e'require Foo'
Too late to run CHECK block at Foo.pm line 2.
Too late to run INIT block at Foo.pm line 3.
$ perl -e'use diagnostics; require Foo'
Too late to run CHECK block at Foo.pm line 2 (#1)
    (W void) A CHECK or INIT block is being defined during run time pr
+oper,
    when the opportunity to run them has already passed.  Perhaps you 
+are
    loading a file with require or do when you should be using use
    instead.  Or perhaps you should put the require or do inside a
    BEGIN block.
    
Too late to run INIT block at Foo.pm line 3 (#1)
[download]

Yep, you're dead right, guilty as charged;-)

I do 'normally' use both strict and warnings - not quite sure how this got thro' the net.

It might even have saved my question - or at least, when asked, my question would have had a far narrower focus.

A user level that continues to overstate my experience :-))