> Too bad Perl doesn't have ...

    PERL5OPT='-MData::Dumper';
[download]

Why do you always phrase your questions as "Perl doesn't do X" instead of "Is there a way to make Perl do X?"

>> Why do you always ...

You could even boldly ask
"I am sure there must be a way to X in Perl, can anyone please tell me how?"

Rudif :-)

Okay, I think you are asking for Data::Dumper->new() to automatically do use Data::Dumper if you haven't already. Okay, that isn't so hard:

package UNIVERSAL;

sub new {
    my $pkg= shift @_;
    eval "require $pkg; 1"
        or  die "$@";
    return $pkg->new( @_ );
}

1;
[download]

Update: Note that putting it in UNIVERSAL.pm probably isn't enough since I think that file isn't necessarilly parsed despite its name, though PERL5OPT="-mUNIVERSAL" is particularly appealing to me.

txpsj has asked that I explain how this works, so here goes.

All packages implicitly inherit from the UNIVERSAL package. This is like every package's @ISA always ending in 'UNIVERSAL' no matter what you set a package's @ISA to be.

So if you do Data::Dumper->new(), then Perl looks for "sub Data::Dumper::new". If you've already done use Data::Dumper or require Data::Dumper, then Perl finds it and things progress as normal.

But, if Perl doesn't find it, it looks in @Data::Dumper::ISA for packages that Data::Dumper inherits from in case the new() method is supposed to be inherited. But no Data::Dumper::new() means no @Data::Dumper::ISA yet so it is empty. But Perl still implicitly includes the UNIVERSAL package in the list and so looks for "sub UNIVERSAL::new". Well, we've given Perl one to find.

So Data::Dumper->new( "x", "y" ) becomes UNIVERSAL::new( "Data::Dumper", "x", "y" ). So we pull the package name off the argument list and do a require on it. This should define a real "sub Data::Dumper::new" which we then call.

All this brings to my mind some improvements I should make. First, it would be nice to "goto" the real new() so that the call stack doesn't show the extra UNIVERSAL::new() in case new() wants to look at caller(), for example. Also, if require Data::Dumper didn't define "sub Data::Dumper::new", then we'd be in a infinite loop.

So here is a better version (updated):

package UNIVERSAL;

use strict;
sub new {
    my( $pkg )= @_;
    eval "require $pkg; 1"
        or  die "$@";
    my $meth= $pkg->can( "new" );
    die "Package $pkg defines no new() method"
        if  $meth == \&UNIVERSAL::new;
    goto &$meth;
}

1;
[download]

Now put this in AutoNew.pm and change the two lines you always start all of your scripts with to:

#!/usr/bin/perl -w -mAutoNew
use strict;
[download]

Now you can create whatever objects you want without predeclaring what packages you need. This, of course, makes you code harder to maintain and I'd strongly advise against it for production code. But it was fun.
        - tye (but my friends call me "Tye")

Going down this path is dangerous. But since you are going down it, may I suggest the additional hack to use CPAN.pm to fetch the specified module if the require fails? :-)

In this node RE: Factory Pattern for Class Heirarchy, I took this concept to an extreme and wrote up a UNIVERAL::AUTOLOAD method that will load the package when you refer to ANY method in the package. It's a horrible abuse of the UNIVERSAL and AUTOLOAD methods but it was education to learn how they worked and interacted.

As you mentioned, an editor template would probably be the best solution to this.

Another solution (at least under Unix) is to say:

> alias perl='perl -MData::Dumper'

> perl -e 'print Dumper({foo=>"bar"})'
$VAR1 = {
          'foo' => 'bar'
        };
[download]

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

If you only want some (or even most) of your scripts to use a module without putting it in the code explicitly, you could also write a shell script perldd or whatever you want) that does it automatically, à la :

#!/bin/sh

perl -MData::Dumper $1
[download]

You could then call that script instead of the "naked" perl interpreter when you need the extra functionality.

Philosophy can be made out of anything. Or less -- Jerry A. Fodor