I don't seem to have any trouble with what I think you want. Does the following code work for you?

#!/usr/bin/perl

use strict;
use warnings;

package Parent;

sub new
{
    bless {}, shift;
}

sub DESTROY {}

sub AUTOLOAD
{
    our $AUTOLOAD;
    my $self = shift;
    print "Parent called for '$AUTOLOAD' on $self\n";
}

package Child;

our @ISA = 'Parent';

sub AUTOLOAD
{
    our $AUTOLOAD;
    my $self     = shift;
    my ($method) = $AUTOLOAD =~ /::(\w+)$/;
    my $parent   = "SUPER::$method";
    return $self->$parent( @_ ) unless $method =~ /^kid_/;
    print "Child called for '$method' on $self\n";
}

package Grandchild;

our @ISA = 'Child';

sub AUTOLOAD
{
    our $AUTOLOAD;

    my $self     = shift;
    my ($method) = $AUTOLOAD =~ /::(\w+)$/;
    my $parent   = "SUPER::$method";
    return $self->$parent( @_ ) unless $method =~ /^grandkid_/;
    print "Grandchild called for '$method' on $self\n";
}

package main;

print "Constructors\n";

my $p  = Parent->new();
my $k  = Child->new();
my $gc = Grandchild->new();

print "Calling foo() on all\n";

$p->foo();
$k->foo();
$gc->foo();

print "Calling kid_foo() on child and grandchild\n";

$k->kid_foo();
$gc->kid_foo();

print "Calling grandkid_foo() on grandchild\n";

$gc->grandkid_foo();
[download]

My error was that I call the upper AUTOLOAD with the class and not the object.
Your solution is clean and forseable.
That is just what I wanted.
Thks

This works but we loose the CONTENT of $AUTOLOAD coming in Parent::AUTOLOAD.

Then why not just set it?

$Parent::AUTOLOAD = $AUTOLOAD;
$self->Parent::AUTOLOAD(@_);
[download]

Of course this way requires you to know what superclass you want to dispatch too. A more generic solution would involve going through the @ISA array and calling AUTOLOAD on each superclass (if they have an AUTOLOAD that is). The code might look something like this (note: this is highly untested)

if (we can do something) {
   ...
}
else {
   no strict 'refs';
   foreach my $super (@{'${class}::ISA"}) {
       my $method;
       if ($method = $super->can('AUTOLOAD')) {
           ${"${super}::AUTOLOAD"} = $AUTOLOAD;
           return $class->$method(@_);
       }
   } 
}
[download]

But now I ask you, is all this really worth it to save a little bit of repetitive typing by hand-making getters and setters?

I define the attributes of the object just in the overloaded new method.Thus in one place.
Setters and getters are handled centrally by the Parent. So that is not just saving typing it is keeping it compact and avoiding lines and lines of not really value added code.
Let the machine do the boring work and you do the thinking. Is that not the real way of being lazy? :=)
Thanks for your thinking.

I define the attributes of the object just in the overloaded new method.Thus in one place. Setters and getters are handled centrally by the Parent. So that is not just saving typing it is keeping it compact and avoiding lines and lines of not really value added code.

So then all your attributes are public? And attributes which are defined by Parent::Child and Parent::Child::GrandChild are handled by code in the parent? Which means that code in Parent is directly accessing fields which don't belong to it. This is actually bad OO, and just because perl's (some would say broken) OO system lets you do it, does not mean you should do it.

My personal approach (and I am known to be a (sometimes) overly defensive programmer so take it with a grain of salt) is that I never create getters and setters until I actually see a need for one. And IMO it is bad OO design to have your superclass deal with anything which is specific to your sub-class. Your superclass should never need to have any knowledge or deal with attributes of your sub-classes in any way (regardless of how dynamic the code which makes it possible).

Let the machine do the boring work and you do the thinking.

My argument is that you shouldn't need to actually do the "boring" work unless your "thinking" tells you that it is nessecary. At which point you can implement whatever it is in a reasonable amount of time and not have to do it again.

Is that not the real way of being lazy?

No. The real way of being lazy is to do it right the first time (more work up front), so that you don't have to do it again when you realize it's wrong.

AUTOLOAD is an oft abused feature of perl's (akward) OO system. IMO it should be used with great caution, and only when nessecary. It's mis-use has tripped up many an perl programmer experienced and in-experienced alike. The simple fact that it negates any meaningful use of can is IMO enough to not use it.

-stvn

use strict;
package Parent;

sub make_accessors {
  my ($class, @attributes) = @_;
  foreach my $attribute (@attributes) {
    no strict 'refs';
    *{"$class\::$attribute"} = sub {
      my $self = shift;
      if (@_) {
        $self->{$attribute} = shift;
      }
      return $self->{$attribute};
    };
  }
}


package Child;
our @ISA = 'Parent';
__PACKAGE__->make_accessors(qw(this that the other));
[download]

NEXT.pm adds a pseudoclass named NEXT to any program that uses it. If 
+a method m calls $self-NEXT::m()>, the call to m is redispatched as i
+f the calling method had not originally been found.

In other words, a call to $self-NEXT::m()> resumes the depth-first, le
+ft-to-right search of $self's class hierarchy that resulted in the or
+iginal call to m.

[...]

Another typical use of redispatch would be in AUTOLOAD'ed methods. If 
+such a method determined that it was not able to handle a particular 
+call, it might choose to redispatch that call, in the hope that some 
+other AUTOLOAD (above it, or to its left) might do better.
[download]

Sounds like you could use this.

This proves one more time that
"There is more than one way to do it"
Thks