Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Re: global source filters

by BrowserUk (Patriarch)
on Jun 22, 2003 at 22:07 UTC ( #267996=note: print w/replies, xml ) Need Help??


in reply to Re: global source filters
in thread global source filters

Note: I'm not advocating this a good solution to your problem. It is simply the only solution that I can think of to your problem as stated.

The idea of using PERL5OPT & -MYour::Filter could (be made to?) work, given a little imagination and a lot of need.Your correct that -M effectively does a use in the main script, but the combination has several things going for it.

  • Environment vars a a convenient way of enabling/and disabling thing globally.
  • Modules loaded this way are loaded beforethe modules used within the script.
  • The module you are loading is a source filter.

The combination of factors means that your source filter will have the opportunity to filter all the other use & require statements in the main module.

You could therefore, intervene in those statements and apply your own logic to them. You might for example, create a temporary additional libpath to @INC and whenever you see a use or require statement, copy the referenced module from it's standard location to the appropriate place in your extra libtree, adding a use Your::Filter into the source of the module just after the package statement as you copied it. You then pass the use or require statement back to the compiler unchanged. It does it's usual thing of looking in @inc to locate and read the module, except it reads your modified copy from the temporary libtree you added to the front of @INC instead, and whizzo:). You now get to filter the module. Your filter then gets called recursively to filter any modules imported by that module ...

Were I going to do this, I would code my asserts and debug code in the modules as comments rather than code using some notation on the front of the comment to indicate that this is a debug/test line. Eg.

##debug## assert( $thing_to_check ); ##debug## warn 'doobree=', $whatsit;

and the filter, when enabled would look for these special comments and remove the comment card. This simplifies the filter in that you a) only need inspect comments and b) have a very definitive and easy edit to make. It also means that you only need the filter for testing and debugging, and you disable it in production which reduces the overhead for the production code not only by removing the debug and trace code, by also the filtering itself.

That said, unless your test and debug code was already coded this way to start, you would need to edit the 100's of modules to add the comment cards, in which case you may consider it much simpler to write a script to iterate through your 100's of modules and insert the appropriate use Your::Filter after the package statement.

In truth, I probably wouldn't consider doing any of this on my codebase, but then I can't see your codebase, and I don't see the true nature of the problem that you are trying to address. Suffice it to say. If you really need to do this, perl does provide all the tools you need to do it. They may not be as simply to apply as you would like, but there is rarely a time when you could say "It can't be done.".

I thoroughly enjoyed thinking about how I might tackle the problem you posed.

Should you choose to take the mission, I wish you the best of luck, but will deny any and all involvement should you get caught.

This post will self-destruct 15 seconds after you take the idea seriously:)


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


Replies are listed 'Best First'.
Re: Re: Re: global source filters
by steves (Curate) on Jun 23, 2003 at 01:45 UTC

    Oh, I enjoy thinking about it too ... it's coding it that's a pain in the *ss. 8-)

    Along these lines though: I considered just writing a "compiler" that would batch do what you say: Filter out what I want into a separate production tree. Keep both trees and muck with @INC at start-up to point to one or the other. I don't currently have any special install type interface, so the work there is formalizing code installation. I should be doing that anyway, but of the 3 Perl virtues, I have an extra dose of Laziness.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://267996]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2022-01-21 04:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (57 votes). Check out past polls.

    Notices?