http://qs321.pair.com?node_id=218035


in reply to Re: Was my module used or required?
in thread Was my module used or required?

Sorry to be so "silly", but...

If my module get's conditionally require'd inside an eval() then the BEGIN block in my module won't be executed when the application starts it's execution which is what I'm trying to verify.

Update:
I read below: "...the moment it is completely defined ..." which corresponds to my understanding.

Doesn't this mean that an eval("require MyModule") will make sure that MyModule get's parsed in this very moment instead of during compilation of the main script?

If this is so, then any BEGIN block in MyModule will be parsed and executed at eval() time. No?

If this is not so, but all modules are parsed at compile time even if they are only conditionally required in an eval() statement, how can it be that modules that are not at all available on the system will not create a compilation error as long as the condition is not met and the module is not being actually required?

And how does perl handle when I read in from a database what module to conditionally require in an eval() statement?
(Where the name of the module does not ever appear in my code, but only in a variable brought in from the database.)


Everything went worng, just as foreseen.

Replies are listed 'Best First'.
Re: Re: Re: Was my module used or required?
by PodMaster (Abbot) on Dec 06, 2002 at 11:23 UTC
    Always means alway, well ;)

    from perldoc perlmod

    Package Constructors and Destructors

    Four special subroutines act as package constructors and destructors. These are the BEGIN, CHECK, INIT, and END routines. The sub is optional for these routines.

    A BEGIN subroutine is executed as soon as possible, that is, the moment it is completely defined, even before the rest of the containing file is parsed. You may have multiple BEGIN blocks within a file--they will execute in order of definition. Because a BEGIN block executes immediately, it can pull in definitions of subroutines and such from other files in time to be visible to the rest of the file. Once a BEGIN has run, it is immediately undefined and any code it used is returned to Perl's memory pool. This means you can't ever explicitly call a BEGIN.

    An END subroutine is executed as late as possible, that is, after perl has finished running the program and just before the interpreter is being exited, even if it is exiting as a result of a die() function. (But not if it's polymorphing into another program via exec, or being blown out of the water by a signal--you have to trap that yourself (if you can).) You may have multiple END blocks within a file--they will execute in reverse order of definition; that is: last in, first out (LIFO). END blocks are not executed when you run perl with the -c switch, or if compilation fails.

    Inside an END subroutine, $? contains the value that the program is going to pass to exit(). You can modify $? to change the exit value of the program. Beware of changing $? by accident (e.g. by running something via system).

    Similar to BEGIN blocks, INIT blocks are run just before the Perl runtime begins execution, in ``first in, first out'' (FIFO) order. For example, the code generators documented in perlcc make use of INIT blocks to initialize and resolve pointers to XSUBs.

    Similar to END blocks, CHECK blocks are run just after the Perl compile phase ends and before the run time begins, in LIFO order. CHECK blocks are again useful in the Perl compiler suite to save the compiled state of the program.

    When you use the -n and -p switches to Perl, BEGIN and END work just as they do in awk, as a degenerate case. Both BEGIN and CHECK blocks are run when you use the -c switch for a compile-only syntax check, although your main code is not.


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    ** The Third rule of perl club is a statement of fact: pod is sexy.