However I also provided some overloading condition to be made on the %ENV by other modules, so the contents inside the BEGIN maybe need to rerun (and some extra modules maybe import), thaz why I pulled the codes out from BEGIN and form a sub (coz BEGIN can't export), so BEGIN and other modules can share the same operations.

What I still don't understand is why use subs lost this race. Say:

use strict;
use subs "TestMe";

BEGIN {    $x = 10; TestMe(); }
sub TestMe {"Test fine"}
[download]

Thanks, I am using the BEGIN block ... instead of creating another module

You don't need a BEGIN {} block to import/export or touch %ENV (icky like a code smell potentially almost), just simply make another module :) do stuff in import, it takes args

use Local::TouchEnvFirst; ## import
use Local::TouchEnvSecond  -optionFantastic;
use Local::TouchEnvSecond  -optionNotFantastic;
no Local::TouchEnvFirst; ## unimport
no Local::TouchEnvSecond -tooComplicated;
use Local::Madness -init => sub {
   warn "if you gotta run me, go ahead :)";
};
[download]

Does the light bulb turn on? :)

What I still don't understand is why use subs lost this race. Say:

Same reason, it doesn't define the subroutine, its a forward declaration, its exactly like this literal code

sub TestMe;
BEGIN { TestMe }
sub TestMe { warn "oh no you didn't" }
__END__
$ perl testme
Undefined subroutine &main::TestMe called at testme line 2.
BEGIN failed--compilation aborted at testme line 2.
[download]

 

rm -rf goners

lol~~ I was actually grouping few modules into this one... but your explanation resolved my puzzle now. Well then.. I think I'll leave this little ugly defects for now, I can live with this though ^0^

What I still don't understand is why use subs lost this race.

It didn't. use subs did its thing before the BEGIN block was executed.

You're trying to execute "Test fine" before it even gets read from the source file by the parser!

yeah.. I got it now.. use subs "_init" only declared the sub name, but _init() would only work when it's defined.