in reply to Re: use/require $MODULE (a variable)
in thread use/require $MODULE (a variable)

Look into Exporter's export_to_level function. Somehting like this:

  # in your PmLoader module... 
  sub import 
  {
     ## do whatever you need to do, and then
     eval "
       require $module;
       $module->export_to_level(2);
     ";
     ## obivously, don't forget to check for errors
  }

[download]

Update: On a second thought, not all modules have a export_to_level function, so it's really better to separate out those two statements into two eval() calls... 

   eval "require $module";
   ## check for errors...
   eval "$module->export_to_level(2)";
   ## this one can/may fail, so may be just warn?
   ## or I guess you could check by doing
   ##
   ##   $module->can( 'export_to_level' );
   ##

[download]

Replies are listed 'Best First'.
Re: Re: Re: use/require $MODULE (a variable)
by cadphile (Beadle) on Mar 18, 2002 at 08:08 UTC
    lestrrat -- Thanks very much! The export_to_level(2) works! for modules that are inheriting Exporter.pm. We still have however, many old .pl libraries, some of which are packages, others which are just files of subroutines. Pretty much in all cases, those that are actually packages, don't require Exporter; and the .pl subroutine files certainly don't.

    Now in normal mode, the symbols for the subroutines in the subroutine libfiles would remain in main, since no package name caused Perl to change namespaces. But in my PmLoader, without an export functionality, these remain in PmLoader.

    So in both of these cases, I guess I should concoct a local export subroutine (based on the relevant code in Exporter.pm) to call, since export_to_level() can't be used. Or maybe I should play with package name switching... Again, thanks alot for your help!

    -cadphile.

[reply]
[d/l]
[select]

      Ah, I see, well, there are a few tricks you can do for plain .pl files... you could do (sort of) what Exporter is doing, which is symbol table munging, or you could cheat a little and do something like

         ## beware! very much untested, it's incomplete,      
   ## and it needs lots of error checking.
   use IO::File;

   sub import
   {
      ## if the module is a plain .pl file...
      my $fh = IO::File->new( $module );
      local $/ = undef;
      my $text = <$fh>;
      undef $fh;

      my $caller_pkg = ((caller())[0]
      eval "package $caller_pkg; $text";
   }

      [download]

      Obviously, this is a hack and it won't always work (furthermore, it's ugly). But at least you could *attempt* to load them files to the correct namespace. ;)

[reply]
[d/l]
        I'm tempted to try your suggestion, just because it's a bit arcane, but alas, a very simple solution has been found: Since no .pl file package is exporting (unless it names it's subroutines something like 
        sub main'myfoo {}

        [download]
        there is really no difference in the way I need to handle .pl packages, or just .pl libraries.

        In either case, what I'm doing is:

              if ( $file =~ /\.pl$/ ) {        
         package main;
         #printf("(package::main): require \"$file\"\n");
         eval "require \"$file\"";
         package PmLoader;
      }
      else {
         (my $module = $file) =~ s/\.pm$//;
         #printf("(module): require $module\n");
         eval "require $module";
         #printf("(module): $module->export_to_level(2);\n");
         eval "$module->export_to_level(2)";
      }

        [download]
        This combination works properly for both types of .pl files, and for .pm modules that are Exporters. Hmmm, what if the .pm module doesn't export... I'd better think about that one.

        Thanks! and good night...
        -Cadphile...

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom