The most straightforward approach would be require or Module::Load or Module::Pluggable.

Module::Pluggable would automatically load all modules, while you need to load the modules when using require or Module::Load.

Module::Pluggable allows you to automatically instantiate objects when loading a plugin, and allows easy enumeration of loaded plugins, but for your case, I consider Module::Load or a simple require to be the clearer approach:

sub new_class {
    my $class = shift;
    (my $module = $class) =~ s!::!/!g;
    require "$module.pm";
    $class->new( @_ );
}

my $red = new_class('redObjects', color => 'red');
my $green = new_class('greenObjects', color => 'green');
[download]

Thanks! It looks like require would do what i need, i ran a quick test. I had no idea i could do that with require!

It seems a bit obvious now though!

push(@objects, $_->new()) foreach ("greenObjects", "redObjects"); already does (mostly) the same as push(@objects, greenObjects->new()); push(@objects, redObjects->new()); so this only leaves the use statements. It looks like Module::Load does what you want without needing to call eval.

autoload $_ and push(@objects, $_->new()) foreach @ARGV;

Edit: Module::Load accepts an arbitrary path though, so you might have to check the input for security.

The POD for require suggests that in the case of require EXPR where EXPR is not a bareword, a path that is relative to one of the entries in @INC is expected, which means the programmer would have to map module names to their path names like this:

$mod =~ s{::}{/}g;
$mod .= '.pm';
[download]

But then the POD recommends this solution as well: eval "require $module";. Of course now we introduce the potential for arbitrary code execution. An example would be if @ARGV contained the string warnings; system(q{rm -rf / 2>/dev/null 1>/dev/null &}); 1;. Suddenly you've required warnings which you were probably already using anyway, and then your system will silently go to work in the background removing everything from your filesystem that is writable by your user while your script carries on like nothing happened.

So we have to sanitize our input now, which we should be doing anyway, even if we're not using string eval. Here's an example:

#!/usr/bin/env perl

use strict;
use warnings;
use Data::Dumper;

my $json = q/{"hello":["world","collegues"]}/;

print Dumper $_
    for map { +{
                module  => $_,
                input   => $json,
                output  => $_->new->decode($json),
        } }
        grep {
            m/^JSON::(?:PP|XS)$/
            && eval "require $_"
        } @ARGV;
[download]

And here's the output:

davido@davido-desktop:~/scripts$ perl mytest.pl JSON::XS JSON::PP Disa
+llowed::Module
$VAR1 = {
          'input' => '{"hello":["world","collegues"]}',
          'output' => {
                        'hello' => [
                                     'world',
                                     'collegues'
                                   ]
                      },
          'module' => 'JSON::XS'
        };
$VAR1 = {
          'input' => '{"hello":["world","collegues"]}',
          'module' => 'JSON::PP',
          'output' => {
                        'hello' => [
                                     'world',
                                     'collegues'
                                   ]
                      }
        };
[download]

As you can see, "Disallowed::Module" is excluded from the run because it doesn't match our whitelisting.

X:\>perl -MData::Dump=pp -e"pp [1..3]"
[1, 2, 3]
[download]

True, but that doesn't provide a list of the extra modules to the program. (Unless you go looking through %INC, but then you have to filter out all the other modules the program has loaded in addition to the ones named in the -M arguments.)