A little bit modified, you can/should also check before loading if it is already loaded:

for my $mod (@mods) {
    if(!defined($mod->VERSION)) {
        load $mod;
        print "$mod version is " . $mod->VERSION . "\n";
    }
}
[download]

you can/should also check before loading if it is already loaded

You can, but should you? What benefit is gleaned by doing so?

If I simply double up the array of modules the script runs without error or warning and produces the expected results:

#!/usr/bin/env perl 
use strict;
use warnings;
use Module::Load;

my @mods = ('JSON', 'CGI::Lite');

for my $mod (@mods, @mods) {
        load $mod;
        print "$mod version is " . $mod->VERSION . "\n";
}
[download]

You can, but should you? What benefit is gleaned by doing so?

Mostly performance, depending on what you do. For example, my Maplat Webserver stuff loads/configures lots of "web modules" from XML config files on startup. Each "web module" maps to one of a hundred or so perl modules (but many "web modules" use the same perl module, just with different config options on different URIs). It checks if $VERSION is defined, and if not, it loads the perl module, so it doesn't have to load them multiple times. Seems to save a bit of time on startup, which is quite handy while debugging.

My system also notifies me which perl modules are dynamically loaded (instead of already loaded with "use"), which is also quite useful in some circumstances.

"For me, programming in Perl is like my cooking. The result may not always taste nice, but it's quick, painless and it get's food on the table."

Module::Load

I was surprised to find this two-year old bug report:

Module::Load::load is vulnerable to path traversal attacks, and this is by design (because load() can load both modules and arbitrary files) and can't be fixed.

I haven't looked into it deeper yet, but if true, that could be a potential drawback to this module when using user-supplied strings.

that could be a potential drawback to this module when using user-supplied strings.

Technically, that's true. However ISTM that it's much the same as saying that DBI is vulnerable by design because putting user-supplied strings into a do() or prepare() call could result in SQL injection. But that's OK because nobody in their right mind would write code which passed unvalidated user-supplied data to such methods. And the same is true for Module::Load. Perhaps moreso because in the latter's case it is easily blocked by taint mode:

$ cat tm.pl
#!/usr/bin/perl -T
use strict;
use warnings;
use Module::Load;

my $garbage = shift @ARGV;
load $garbage;
print "This is fine.\n";
$ ./tm.pl foo
Insecure dependency in require while running with -T switch at /usr/sh
+are/perl5/vendor_perl/Module/Load.pm line 77.
Insecure dependency in require while running with -T switch at /usr/sh
+are/perl5/vendor_perl/Module/Load.pm line 77.
$
[download]

YMMV but I'm perfectly happy to carry on using it in a secure fashion.

it's much the same as saying that DBI is vulnerable by design because putting user-supplied strings into a do() or prepare() call could result in SQL injection

Well, yes and no: I'm saying that yes, it's a security issue like code injection, both in that it should be seriously considered and warned about, but also in that if you are aware of the issues and know what you are doing and can use it safely, then fine. But no, it's not exactly like DBI's API, because apparently Module::Load chose to overload its load function to be able to load both modules and files, which could have been designed differently to avoid this issue.

nobody in their right mind would write code which passed unvalidated user-supplied data to such methods

Well I've seen it done one too many times, and so this statement could also be read with a sarcastic meaning ;-)