in reply to [RFC: Module proposal] Tracing sneaky EXPORTs using wrappers

This seems like a good idea. I'd like to know a little more though:

I think that if you're going to release this to CPAN, you should put some extra thought into making it potentially useful not just for the task your doing, but also other similar tasks, without making the original idea any less convenient. In fact, I think you shouldn't implement anything you don't need, but design so that it's easy to add and put a comment in the documentation saying that you're open to suggestions and patches.

A synopsis and a brief summary of the implementation would really help.

lodin

Replies are listed 'Best First'.
Re^2: [RFC: Module proposal] Tracing sneaky EXPORTs using wrappers
by krazyk (Beadle) on Apr 11, 2008 at 18:21 UTC
    Here's the synopsis: 
        SYNOPSIS

    # Wrap all subs in default code to warn on entry/exit, displaying 
+args and return values...
    use Devel::WrapExports;

    # The same thing, but ignore the specified packages and subs...
    use Devel::WrapExports
        exempt_pkgs => [ qw( Devel Carp CGI ) ],
        exempt_subs => [ qw( Nevermind::me ) ];

    # Use my own subs for tracing instead of the defaults...
    use Devel::WrapExports
        pre   => q{ sub { "custom pre-wrapper..."  } },
        post  => q{ sub { "custom post-wrapper..." } };

    # Run as script to list fully-qualified names of each symbol (sub 
+or otherwise) in the top-level scope...
    $ perl /path/to/Devel/WrapExports.pm <perl-source-file>

    [download]
    Some more background:

    Initially, I only wanted to know where to go to find the source of hundreds of imported subs in code that I was looking at. Then, I realized that if I could automatically wrap all imported subs with warnings on entry/exit, I could get a nice trace in Apache error logs.

    Currently, the technique is to look at all packages that are explicitly 'use'd or 'require'd by the caller (these are found by examining the caller's source code), then find all symbols that each of those packages export (this is done by looking at the contents of @EXPORT and @EXPORT_OK in each of these packages' symbol tables, so it's not compatible with non-Exporter.pm exporters). For each such symbol that is a sub, exploit Hook::LexWrap to wrap the sub (the one already imported into the caller's package) with "tracing code" as implied in the SYNOPSIS above (e.g. default or custom tracing subs).

    Your question about handling non-Exporter.pm exporters is a good one. I hadn't considered that in my focused mindset. I plan on adding that support. It will be a matter of looking at the caller's symbol table instead of the caller's source (which is almost certainly a better approach anyhow).

    So, in summary:
    • I'm planning on supporting non-Exporter.pm exporters.
    • Only subs are traced (by design), using Hook::LexWrap (but calling the module as a program shows all types of symbols in the package of the argument).
[reply]
[d/l]

      The name
      If you plan to support only subroutines I don't think it should be called Devel::WrapExports. That name sound more generic and the way I interpret it is that the exporter mechanism will be wrapped to allow me to inspect everything that was exported. I don't know what a better name would be, but the uncommonly long Devel::WrapImportedSubs doesn't seem to bad after all. Imperfect as it may be the concept is clearly communicated. "Devel" - it's to help development; "wrap" - you do something upon each call; "imported" - only imported subroutines are of interest; "subs" - only subroutines are of interest. Note that I suggest "imported" over "exported" because you do it from a caller perspective. The package doing "use Devel::...;</c> later imports from the modules it uses. "Export" makes sense from the module author's perspective (like used as Exporter.pm), e.g. if a module Foo wanted to register every case of use Foo;.

      The interface
      I think that you have a good interface. However, I think you should open up to other ways of wrapping. Hook::LexWrap is convenient, but it can also break code that relies on caller(). It's possible (and simple) to do a completely transparent pre-hook, so another way to install the hook is quite important.

      The implementation
      Good luck. I think you'll need it. :-) It's quite a complicated task; there are several tricky cases. I'm looking forward to seeing how you solved it.

      lodin

[reply]
[d/l]
[select]
        Your naming advice makes perfect sense to me. However, after more consideration of the implementation goals I had proposed, I'm now wondering if I should be a bit less ambitious and settle for something that will probably be just as useful anyway. I believe my original plan to deterministically identify the origin package for imported symbols would be more realistic if I drop the goal of supporting non-Exporter.pm exporters.

        You're right about the edge cases -- there are some tough ones. I believe that most of the ones I've thought of are within reach. For instance, one interesting problem is identifying which of all the use()d modules contributes symbol S to package P (or if S just came from P itself). I believe I could create a private, empty package in which a candidate module could be use()d, then check the resulting symbol table of the dummy package for symbols. The resulting set of symbols would represent those exported by the module's import().

        However, symbols not found this way might still have come from those modules (e.g. the package in question could require() a module M, then call M::import_deceptively(), which may do what import() conventionally does)! The probability of false negatives would be very low, but I can't think of a general way to positively conclude that a symbol has not been imported.

        I have a new appreciation for Exporter.pm, much maligned as it has been at times. As it is standard for Perl, placing dependence on it as a precondition for my module's efficacy seems reasonable.

        Here are the updated goals for Devel::WrapImportedSubs:
        • Wrap subs that use()d modules have exported via Exporter.pm (by looking for @EXPORT and @EXPORT_OK in their symbol tables)
        • Optionally wrap subs defined by the caller and fully-qualified subs called from other namespaces (since it would seem that users (like me) who need to do tracing would expect and need this easy-to-add feature)
        I'll think about alternatives to Hook::LexWrap.

        Thanks for help with advice on the design!
[reply]

In Section Meditations