In a recent mailing-list thread about creating a lightweight module, someone suggested putting 
#use strict;

[download]
in, to be uncommented during development of the module and recommented for release.

I immediately thought of this: 

use if $INC{"strict.pm"}, "strict";

[download]
This enables a global stricture setting; use strict unqualified at the beginning of your main program and you automatically get it turned on in all scopes specifying the above line. Then you just have to use strict in your tests and you get automatic strictures during development - but not in production if strict hasn't been already loaded.

Unfortunately, this requires loading the if module...I sometimes regret that Ilya's original use foo if bar syntax wasn't implemented.

Replies are listed 'Best First'.
Re: evil code of the day: global stricture control (micro)
by tye (Sage) on Aug 02, 2007 at 01:30 UTC

    strict.pm contains about a dozen lines of executable code, none of which does anything particularly expensive. Is there some reason you consider that tiny bit of code a big enough deal to try to eliminate? It seems like micro-optimization to me, something unlikely to be worth doing.

    But your problem is easy to solve: 

    BEGIN { strict->import( ... ) if $INC{"strict.pm"} }

    [download]

    - tye        

[reply]
[d/l]
      I did say "evil". I was expecting someone would propose your code (only it needs to be "strict"->import if strict is not loaded); also $ENV{TESTING} or some such instead of $INC{"strict.pm"}.
      Is there some reason you consider that tiny bit of code a big enough deal to try to eliminate?
      It wasn't me considering it: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-08/msg00055.html (the >>'d text is not Max).
[reply]
Re: evil code of the day: global stricture control
by chromatic (Archbishop) on Aug 02, 2007 at 04:56 UTC

    I don't see the value in this, especially as loading if is more work!

    The only sillier optimization I've seen is a flurry of patches removing use Carp; from core modules and replacing every use of an exported subroutine with the require Carp;  Carp::foo(); dance.

[reply]
[d/l]
[select]
      I consider using Carp module only when needed useful, because Carp uses Exproter, which I really hate and try to avoid.

      Another reason for such a dance is my own approach to bootstrap lightweight Perl+Tcl::Tk, much like PAR but without temporaries and with on-the-fly in-memory unzippings, where my first module (Tcl.pm) will not see anything, because perl library forest is not established yet.

[reply]

        I'm guessing the chances you can get a perl process that has no Exporter.pm are zero to nil. I don't think your avoidance of Carp on the principle of also avoiding Exporter is sound.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]

        The problem is that the patch to load Carp lazily actually added more code to the core than if the author had left well enough alone. Carp itself is tiny.

[reply]
Re: evil code of the day: global stricture control
by moritz (Cardinal) on Aug 02, 2007 at 06:57 UTC
    Why do people insist on installing delayed bugs into their scripts?

    Did they even benchmark if removing use strict; had a significant performance impact?

    I just don't get it...

    Perl 6 in German

[reply]
[d/l]
      Try drinking alcohol :)
[reply]
Re: evil code of the day: global stricture control
by grep (Monsignor) on Aug 02, 2007 at 14:16 UTC
[reply]

Back to Meditations