Personally I don't think there is anything wrong with this under controlled circumstances - I have plenty of code that does the same thing within an AUTOLOAD to create the autoloaded subroutines in the symbol table and of course it has to use "no strict 'refs'"

An alternative might be to create coderefs for the subroutines within the object itself (or if an object has not been created at that point in a package variable) and then use AUTOLOAD to run that code.

This might look look something like:

   $self->{$method} = sub { my $self = shift; # etc };

   ...

   sub AUTOLOAD
   {
     my ( $self, @args ) = @_;

     (my $method = $AUTOLOAD) =~ s/.*:://;

     if ( exists $self->{$method} )
     {
         return $self->{$method}->(@args);
     }
     else
     {
       die "Not a method";
   }
[download]

Of course this doesn't actually ever create the method in the symbol table so that UNIVERSAL::can won't work and inheritance won't work as expected :( - If you really need those things then don't worry about using no strict 'refs' it is really only an indication to perl that you recognize you are doing something a little out of the ordinaru but you promise not to do it all over the program :)

/J\

To answer the question asked elsewhere about AUTOLOAD, there are several advantages. First of all every time you need to change the symbol table you throw away the method cache. If you think most of your methods are going to get called eventually then it makes sense to only pay that once.

That one is relatively unimportant though. The big one is that you now are not forced to put all of your dynamic logic in one place. With AUTOLOAD you need to put all of your dynamic logic in the first AUTOLOAD. And if you have a subclass which should work just like its parent but with a minor tweak...you need to duplicate logic. But with this code the dynamic bit only affects what it needs to at the level it wants to and can override and be overridden in a fine-grained manner. This gives quite a bit more design flexibility than AUTOLOAD offers.

THanks for the comments.. Your line of thinking is just as mine is. I think it makes things easier to read... I also have more control than AUTOLOAD ... I think, provided you know the syntax, this solution is actually easier to maintain.

Basically, doing this isn't a Bad Thing(tm), just that some people may not understand it. No problem. Thats what the Perl Monks and ORA are for ;-)

Just make sure that you comment it. Heavily. You're doing something "Weird and Strange"(tm). Don't assume that anyone is as smart as you, or thinks in the crazy ways you do. Always assume that the person after you was told "Here's the Perl manual. Read it, then maintain this code." Be nice to them. :-)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

rdfield

Was using it at first. I thought it might be faster without the autoloader... if there are many child classes all the lookups would take more time than just creating real methods once at init. At least that seems to make sense.

What do you mean 'just creating real methods once'?? AutoLoader can create the methods once (during the first call) then you can goto the method (this is considered a 'good' goto). I'm also not saying this is better than your way, the only advantage to this way is that the method never gets created if its never called.

If you were concerned about performance, you wouldn't be using OO, see perltoot.

rdfield