Installing a hook in @INC would be considered "cheating", as the lib::lexical's job is to add specific entries to @INC as instructed and not install extraneous one not specified by user. But I'm still willing to consider using this technique.
As for source filter, I'd rather not go that route.
| [reply] |
Installing a hook in @INC would be considered "cheating", as the lib::lexical's job is to add specific entries to @INC as instructed and not install extraneous one not specified by user.
It is, however, the only way that I can see to make such a change to @INC truly lexical in scope, since it's a global (package) variable. In this node, you seem to be saying that dynamic instead of lexical scoping is enough? Also, it would be good if you could clarify whether you want this effect at compile time, such that it affects use, runtime (like in your example in the root node), or both?
As for source filter, I'd rather not go that route.
Note that LanX's Filter::Inject is different from a traditional source filter in that it only injects code, and doesn't rewrite anything, which makes it much safer to use than traditional source filters. See also his very interesting and enlightening recent talk Fun with Macros.
| [reply]
[d/l]
[select] |
I do want it to affect 'use' too, as well as require/do.
Note that LanX's Filter::Inject is different from a traditional source filter...
Color me intrigued. Checking the module as well as the talk. Thanks!
| [reply] |