For a random instance, if I initially write the class so that a set of properties are exported based on the structure of the object, and I restructure the object, I can just add a few new methods to calculate the things that AUTOLOADER is not doing for you. As long as you remember that your interface needs to be stable, there is no problem with autogenerating large chunks of that interface. After all - thanks to the same principle that you are trying to invoke - there is no need to know or care about the implementation as long as it does the right thing.

And from a maintainability point of view, autogenerated interfaces can be very, very useful. They can be used to avoid a lot of manual synchronization between pieces of code. (Just try to write a class that proxies off of another transparently without them!) Which is why many OO languages offer equivalents to AUTOLOAD. Perhaps it is called something like method_missing. BFD. It is the same thing and can be used in the same way for about the same things.

Ah, I think I see where the misunderstanding lies.

You ("you" meaning zigster) are assuming that I'm autogenerating methods based on the underlying object implementation. That's not what I'm talking about. I'm talking about generating methods based on some other standard, like so:

Note: code based on working code and Camel, but untested

package Foo;

use strict;
use vars qw($AUTOLOAD %ACCESSOR_TABLE);
use Carp;

%ACCESSOR_TABLE = (
    'name' => '_name',
    'id' => '_id_code',
    'phone' => '_phonenum'
);

sub DESTROY { }

sub new {
   my $type = shift;
   my ($name, $id, $phone) = @_;

   my $self = {
     _data_table => { _name => $name,
                      _id_code => $id,
                      _phonenum => $phone,
                    },
   };
   bless $self, $type;
   return $self;
}

sub AUTOLOAD {
    my ($sub_name) = $AUTOLOAD =~ m{.*::(.*)$};
    $sub_name =~ /^get_(.*)/ or croak "Can't autoload method $AUTOLOAD
+";
    my $data_name = $1;
    defined $ACCESSOR_TABLE{$data_name}
        or croak "Can't autoload method $AUTOLOAD";
    my $field_name = $ACCESSOR_TABLE{$data_name};
    *$AUTOLOAD = sub {
        (ref($_[0]) && $_[0]->isa('Foo')) or croak "Accessor method '$
+sub_name' called improperly";
        return $_[0]->{'_data_table'}{$field_name};
    };
    goto &$AUTOLOAD;
}
[download]

use Foo;

my $foo = Foo->new('jenny', '24601', '408-867-5309');
my $phone = $foo->get_phone();
my $name = $foo->get_name();
[download]

These are implementation details; I just want to show that there are legitimate uses for AUTOLOAD in an object-oriented context. And once again, this illustrates the power of OO. From the perspective of the class user, it doesn't matter whether I've defined individual subroutines or if I've got them autoloaded instead. The class user doesn't need to understand "what is under the hood."

stephen

Update: Added an 'accessor exists' check.

There is a FarSide cartoon of a court scene with a lawyer interogating a cow in the witness box: "We want to know why, Brown Cow. We know how now, brown cow.".

It seems odd to me that zigster said "I think AUTOLOAD is bad for munging accessor methods and mutators" and you reply in, so many words...."no you don't understand, this is how it's done". I bet you could write a similar function in Java with clever use of exceptions. you wouldn't want to do it in a Java though, it'd be a hack (If it's a hack in Java then....)

The addition of the exists function kinda highlights zigster's argument (although I fear the repecussions of Scott's opinion being affirmed, it's not something we like to encourage ;). It's like using AUTOLOAD to do overload functions on strict datatypes by using a regex to check the content of parameters. The difference is one is necessary and the other is unnecessary (but admirably lazy ;0)

--

Brother Frankus.

I think you missed stephen's point.

zigster's argument against using AUTOLOAD was that (by his understanding) it tied the methods to the object's implementation and that exposed internal information that you shouldn't expose.

There are two major things wrong with that argument.

My response was that if you choose to tie the autogenerated methods to the implementation, when you change the implementation it is not hard to add normal methods that maintain the old interface even though the implementation changed.

stephen's response is that zigster's assumption that you had to tie the interface to the implementation was wrong. And he replied with actual code showing how to autogenerate methods based on a data structure that can be used to control the interface independently from the internal data structure.

So yes, stephen is munging accessor methods and mutators with AUTOLOAD. However he has done it in a way where changes to the structure of the object do not show up in the interface.

As an incidental note, I have used AUTOLOAD for a variety of things, but I have not yet used AUTOLOAD as a way to produce accessor methods and mutators for end-user objects. However I have used it as a replacement for auto-generated SWIG tie implementations (IOW for objects that Perl is using) with lazily implemented run-time accessors. It worked well. I got both loading and runtime to be substantially faster than the original. Maintainability was the same.

Based on that I have to say that I find AUTOLOAD to be no more or less maintainable than any other way of auto-generating code. If you think about trying to write self-modifying assembly you would think that auto-generated code is the worst idea in the world. However then you go out and use a compiler that does what? Oh right, it autogenerates code to run later!

AUTOLOAD should have a huge sign on it saying, "use with extreme caution", but it doesn't need one saying, "you should never use this".

That said I use it in only a tiny fraction of my code. But that fraction tends to be key code which a lot of other code builds off of...