Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday August 13, 2007
03:30 AM

use or require?

[ #34094 ]

Last night, in working with Devel::Recreate (suggest a better module name, please!), I discovered that it's devilishly difficult to differentiate between use and require or capture import lists. After discussions with Andy Armstrong, the only thing I could think of is either coderefs in @INC or overriding *CORE::GLOBAL::require. I can't tell if either solution allows me to differentiate between the use and require. The only thing I could think of is that use is basically this:

BEGIN { require Module; import Module LIST; }

In other words, if require is triggered, I could use HookLexWrap to wrap the import statement (considering inheritance, of course) to fetch the import list. I'd also have to write some XS code to try and grab PL_beginav to find out if the require happened in the BEGIN phase. Thus, the following would be considered a use statement:

BEGIN {
    require Some::Module;
    Some::Module->import(@args);
}

Naturally, this is all very rickety. Is there a better way to do this?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • First of all, “Devel::” is reserved for things to be loaded using perl’s -d flag. (It should have been a more specific namespace, really, so people wouldn’t be tempted to dump random junk in there that has nothing to do with -d, maybe DB::Custom:: or something.)

    Also, “Devel::Recreate” gives no indication whatsoever about what it recreates. That would be a package, which suggests that the right TLNS for your module is “Package::”.

    Now, what does it do with a

    • I knew I could count on you to smack me around. Thanks :)

      • Oh dear, on re-read, that comment sounds a little more vigorous than I intended. :-) Sorry. Wasn’t meant to be slap-around. I know most people find naming much harder and more tedious than I do.

    • Maybe, Package::OpCodeDumper?

      Then again, it isn't the opcodes, at least from my weak grasp of the internals, is it?
      • Nope. Not trying to dump opcodes, though I may be forced to dig into them at some point. Just trying to dump what perl thinks the source code looks like.

        • Isn't this about dumping how much of the module exists when it dies during load? Seems like caller() from a $SIG{__DIE__} hook and a line number would suffice. What am I missing? Are you trying to get valid perl output, or just information?

          To really do it right, I think you end up source filtering (PPI?) everything (unshift(@INC, sub {...})) into s-expressions or something. I've always wished perl were more introspective, but it seems like syntax is the enemy of introspection (and I really like syntax,