And remember, one doesn't even have to worry about fiddling with the prefix. If you don't do anything else, the perl binary itself will be installed as (for instance) perl5.9.5, so it is not going to overwrite your existing 5.8 (or earlier) perl.

Then, one just has to change to the development directory of a module, and run

    perl5.9.5 Makefile.PL && make all test
[download]

Note that Module::Build is bundled with bleadperl, so you can run perl5.9.5 Build.PL and it should Just Work.

I have a dumb question. I'm not familiar with the idiom you described above. Admittedly, this may be due to the fact that I haven't delved too deeply into the innards of CPAN modules or prepared any Perl modules for distribution beyond work.

Why would somebody do this in their modules:

use warnings;
use strict;

sub complain {
    require Carp;
    Carp::carp "This should not work!"; # Or whatever
}
[download]

use warnings;
use strict;
use Carp;

...
[download]

chdir to your Perl's lib directory and search for *heavy*. The idea is to not immediately load things which take (small, but sometimes not insignificant) time to load if you are likely not going to use them. "require Exporter" now delays loading most of the code that used to be in Exporter.pm until such time as someone uses an "advanced" feature of Exporter.pm. At that time it loads some "Exporter*heavy*" thingy (there is some variability in the details of how each of these is done, but "heavy" seems a common component). Other heavily used modules do similar tricks.

At some point, at least one module author decided to delay loading Carp.pm until such time as a need for it was demonstrated. I'm not sure how good the evidence was that motivated this decision, but the idea was followed by other module authors under the assumption that there was good enough reason for one to go through this small bit of extra work.

In any case, I do it in some of my modules out of what some would call "cargo cult" practice and some would call "best practices", depending on whether they want to make such look bad or good.

But I'm well aware of the pitfalls of conditional compile-time magic and so don't leave off my parens. Actually, my soon-to-be-released module does:

sub _croak {
    require Carp;
    return \&Carp::croak;
}

sub Whatever {
    _croak->( "Usage: Whatever()" )
        if  0 < @ARGV;
[download]

(because I don't like depending on the sometimes-inappropriate "intelligence" Carp tries to apply to skipping stack frames to be reported)

- tye        

In a typical run, carp is not needed, so Carp is only loaded when needed in an effort to speed up the program.

However, the savings are negligible unless the script is called frequently. And if the script is called frequently, the savings are eclipsed by those that would be obtained by using a persistant process.

There's really no reason to do this. Carp is a lightweight module.

There's really no reason to do this. Carp is a lightweight module.

Although the proponent(s) of this practice have yet to post data to back it up where I recall having seen it, I don't recall you having posted data to support your claim either. Note that this practice predates the following in Carp.pm:

    require Carp::Heavy unless $INC{"Carp/Heavy.pm"};
[download]

Note that I get quite a kick out of the last half of that statement. I'm sure the very first thing that require does is exactly that anyway, so I'd never add such trivial code in an obvious attempt at micro-optimization. But perhaps this whole hubbabaloo is just micro-optimization. (Update: Which brings up my long-standing catch phrase, "Nothing is obvious unless you are overlooking something" -- see ikegami's reply below.)

It is my belief that more than just unfounded attempts are micro-optimization were required to motivate so much reworking of these modules. I could certainly be wrong in that belief, but your say-so isn't enough to convince me otherwise.

Also note that I delay loading Carp.pm for my own reasons that I find few people share. I don't load modules that I likely don't need because I don't like my modules failing in those rare environments when some module that most people presume that everyone has is actually missing. I've certainly run into such environments many times. In fact, checking my soon-to-be-released module, the code I wrote is actually:

BEGIN {
    my $croak;
    sub _croak
    {
        if(  ! $croak  ) {
            if(  eval { require Carp; 1 }  ) {
                $croak= \&Carp::croak;
            } else {
                $croak= sub {
                    die @_;
                };
            }
        }
        return $croak;
    }
}
[download]

Which means that my module works fine even if Carp.pm is nowhere to be found.

Update: I also get a kick out of the fact that most of the code has been moved out of Carp.pm and yet "require Carp" has to read over a ton of POD in order to get to that small bit of code. I'd micro-optimize that as well and move the POD after __END__. (:

- tye        

Lazy loading. If you don't need the module, don't load it.

--MidLifeXis