Larry Wall wrote in perl.perl6.language :
>: In perl 5 those blocks are executed at the
>: transition between the compilation and the execution phase *of the main
>: program*. This is convenient for some purposes (the O and B::* modules)
>: and inconvient for others (Attribute::Handlers, etc. etc.).
>
> Hmm, well, I think it's a problem with Attribute::Handlers only because
> that interface binds too late by default. Perl 6 traits will run at
> BEGIN time by default. (Though you can define actions at trait time
> that don't run till a later phase.) Can you elaborate on the etc. etc.?
Of course :) the main problem is not that CHECK blocks are executed
late (just at the end of the compilation phase); it's that they're
executed too early, notably in some persistent environment, notably
mod_perl (or mod_parrot in the future.) When you have a virtual machine,
you'll end up including modules at run time, because the main
compilation phase becomes less important. Thus CHECK blocks become
worthless, code-reusability-wise.
> The "link" phase is still controlled by the main compilation pulling
> in other modules, so CHECK still has the same semantics for the main
> program, at least. And for consistency (especially with Perl 5),
> a CHECK block from a separately compiled module probably should wait
> till end of "link" time to run. Particularly since we have modules
> that specifically create a CHECK knowing it runs at the end of the
> main compilation.
But, as I was saying, modules have no control on what the end of the
compilation is; notably, they've no control on whether it's still
finished.
> my @x will unitcheck {...} # at UNITCHECK time
"your next mission is now to put something like this in Perl 5..."
