in reply to Re: retailed (embedded) perl
in thread retailed (embedded) perl

Your is a really interesting solution.
I tested both
BEGIN { unshift @INC, sub { warn "loading $_ 1\n"; return } }
use lib sub {warn "loading $_ 1\n"; return };
and it works,
but is not clear to me why sub is executed each time
perl scan directories for find an use module
can you explain me more aboute this feature ?
Regards, Enzo

Replies are listed 'Best First'.
Re^3: retailed (embedded) perl
by ikegami (Patriarch) on Sep 06, 2006 at 16:14 UTC

    In addition to paths, @INC can contain code refs (and a couple of other things). When trying to load a module, Perl iterates over @INC until the module is loaded. If a path is encountered, Perl looks for the module in that directory. If a code ref is encoutered, Perl calls the code ref with the name of the module to load.

    The snippet places a code ref at the @INC's head, causing it to be called first. When called, it displays the name of the module Perl is attempting to load. It doesn't load the module, so Perl proceeds with the next entry in @INC.

    References: @INC, require

      a very good explanation
      tanks a lot

        You may also be interested to know why Perl supports coderefs in @INC.

        One reason is so that tools like PAR, which bundle up a Perl script and all of its dependencies, can extract .pm files from the archive on-the-fly as the modules are 'required' by the calling script.

Re^3: retailed (embedded) perl
by zentara (Cardinal) on Sep 06, 2006 at 15:32 UTC
    can you explain me more aboute this feature ?

    What do you think I am.... a Saint? :-)

    I just had that from an earlier post by some Saint like abigail..... it's magic. :-)


    I'm not really a human, but I play one on earth. Cogito ergo sum a bum