in reply to Re: Autovivification with require
in thread Autovivification with require

I was under the impression that best practice is to name files to be brought in with require as *.pl and those being brought in with use as *.pm. I have no idea where I got this notion from, it was a long time ago - at least 2 decades - and I have been doing it that way ever since.

Almost every script I write has a require or three at the top for bringing in code I have created. Most have a few use statements for other people's modules. Over the years I have created a handful of OO modules which get included with a use statement.

Have I been doing this wrong all these years or has best practice changed and I never noticed?

Replies are listed 'Best First'.
Re: PM vs PL
by choroba (Cardinal) on Nov 20, 2020 at 22:34 UTC
    I came late to the Perl game, but I've met required pl files in very old code. So I'd guess the best practice has changed.

    Update: I even discussed it here.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]

      Yeah...I'm guilty of learning what I needed to learn to make things work, then not learning much else until I needed to make something else work. So having learnt to require *.pl files, I have just kept doing it.

      Maybe I could claim I write fashionably retro code :P

[reply]
[d/l]

        My first reaction on seeing require of a .pl file is that it is very old code. I would call it a code smell.

        I prefer to put as much code as possible in CPAN-style modules (.pm files), with associated unit tests (.t files) for each module.

        The ideal is for commands (.pl files) to be very very short, with almost all automated testing heavy lifting delegated to the module level, leveraging the excellent Perl CPAN module testing tools, such as the prove command. An extreme example of this approach is Perl::Tidy whose perltidy command is essentially just: 

        use Perl::Tidy;
my $arg_string = undef;
exit Perl::Tidy::perltidy( argv => $arg_string );

        [download]

[reply]
[d/l]
[select]
Re: PM vs PL - oh there is PMC too!
by bliako (Abbot) on Nov 21, 2020 at 13:06 UTC

    I would like to mention a 3rd type of "include": a PMC file which is "compiled" Perl code, see e.g. Module::Compile (or: what's this PMC thingy?). (Edit: also this is of interest Perl v5.6.1 looking for .pmc files)

    I don't know whether this project is stil alive but I just confirmed that if a Test.pmc file exists alongside an Test.pm , use Test; will attempt to load Test.pmc first (question: can they be in the different INC dirs?).

    Caveat: Because my systems's module compiler (perl -MO=Bytecode,-H -MTest -e1 > Test.pmc) fails with: Can't locate object method "ix" via package "0" , I just touch Test.pmc and surely I get a segfault upon running my script as expected from loading rubbish. The important thing is (i believe) an attempt to load Test.pmc is done. When I delete Test.pmc all runs well, the Test.pm is loaded.

    bw, bliako

[reply]
[d/l]
[select]

      The documentation for require does specify that *.pmc takes priority over *.pm files.

      Before require looks for a .pm extension, it will first look for a similar filename with a .pmc extension. If this file is found, it will be loaded in place of any file ending in a .pm extension. This applies to both the explicit require "Foo/Bar.pm"; form and the require Foo::Bar; form.

      The documentation for use doesn't seem to mention *.pmc files.

      Why would one want to pre-compile the code to include?
      My guess is that it gives better performance as the code doesn't need compiling when the script is executed and/or that it provides better security as it is significantly more difficult to look at compiled code and work out what it is doing and how...

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom