Re: Re: Carp; errors ala DBI

[rir]

Yes, I am serious. Update: But use the relatively new NEXT and all the problems can go away.

AUTOLOAD is a powerful and facile tool: a beautiful thing.
I like it a lot. So there can be overriding motives to use
AUTOLOAD, but if possible it is to be avoided by module
publishers.

It is a name greedy pig.

The way Perl resolves a call is:

1. Seek routine in package.
   
2. If method: seek method in base classes.
   
3. Seek AUTOLOAD in package.
   
4. If method: seek AUTOLOAD in base classes.
   

The following code demonstrates the problem.

#!/usr/bin/perl -w
use strict;

package Mumma;
use vars qw( $AUTOLOAD );
sub AUTOLOAD { 
    print "$AUTOLOAD resolved to Mumma::AUTOLOAD\n"; 
}

package Poppa;
use vars qw( $AUTOLOAD );
sub AUTOLOAD { 
    print "$AUTOLOAD resolved to Poppa::AUTOLOAD\n"; 
}

# Baby doesn't know that Mumma & Poppa are secret AUTOLOADERs
package Baby;
use vars qw( @ISA $AUTOLOAD );
@ISA = qw( Poppa Mumma );   # Order is significant. 
sub new { bless {}, ref $_[0] || $_[0] }

package main;
use vars qw( $AUTOLOAD);

# Baby is supposed to live in a caring universe.
sub UNIVERSAL::AUTOLOAD { 
    print "$AUTOLOAD resolved to UNIVERSAL::AUTOLOAD\n";
}

my $c = Baby->new();

# first &AUTOLOAD found hides rest.
$c->wants_mumma();
$c->wants_poppa();
$c->wants_universal_truth();

[adrianh]

Basically I agree, it can be a problem in complex class hierarchies. However:

• We now have the lovely NEXT that allows us to write AUTOLOAD routines that gracefully decline. I would imagine that it will even be efficient once perl6 hits the streets :-)
• I don't have an issue with AUTOLOAD as long as the module author documents it's presence.
• It's nearly always possible to get around the problem with a bit of trivial object delegation.
• If your code isn't OO it's not an issue