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!

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.