package MyModule;

use OtherModule;

sub new {
    my $class = shift;
    my $obj = OtherModule->new( @_ );
    return bless \$obj, $class;
}

sub AUTOLOAD {
    my $self = shift;
    my ($method) = (our $AUTOLOAD =~ /([^:]+)$/;
    return eval { ${$self}->$method( @_ ); }
}

# These are in UNIVERSAL, so need to be overridden because
# AUTOLOAD won't catch them.
sub can {
    my $self = shift;
    return eval { ${$self}->can( @_ ); }
}

sub isa {
    my $self = shift;
    return eval { ${$self}->isa( @_ ); }
}

1;
__END__
[download]

Yes, I think you are correct in that I probably should have chosen the delegate pattern. Which I think is in reality aggregation, yes? Thanks for the help and the solution proposal:-)

Delegation isn't aggregation. Aggregation is taking many things and calling them by one name, like an array or hash. Delegation is taking one thing and using some other one thing to talk to it, often pretending the latter is the former (which would be more properly called decoration).

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

I don't quite understand why calling the version of funcB from your child class is bad. That's the expected behavior of overridden functions, and if I understand what you're doing correctly, it will just wrap the calls in multiple levels of eval.

I think you've discovered, though, at least one reason why this solution to your problem is extremely cumbersome. After all that work, would it have really been that hard to use evals in the original scripts that were using the exception throwing module in the first place?

Yes. Yes it does. That's the way polymorphism works and is nothing specific to Perl.

package Dog;

sub pull_tail {
  $self->speak;
}

sub speak {
  print "Woof!\n";
}

package AngryDog;

sub speak {
  print "Grrrrr...\n";
}
[download]

(If you wanted all Dogs to react like a base Dog instead of according to their subclass, you could force them to always use the base Dog::speak by changing the $self->speak line to Dog::speak($self), but that's done very rarely, as there are very few cases where it's what you actually want.)

Yes, I can see and understand that logic. I just didn't think that the class I inherited from would know anything about a child. Statically it does not but runtime what is being passed around is as you said an "AngryDog". I was/am confusing static model with the dynamic one.


So for this to work I need to "morph" AngryDog to a Dog prior to asking SUPER to handle. It might even be reasonable to expect "$self->SUPER" to do this.


I think I might also have selected the wrong mechanism, as stated in other reply to my question. Delegation seems maybe the better solution. I must admit though it sure did look like the right candidate for inheritance.

I wonder what happens in this scenario in C++?

Anyways, thanks for the help:-)

It might even be reasonable to expect "$self->SUPER" to do this.

Just to extend my example a little to include that, let's add another method to AngryDog:

sub pull_tail {
  $self->SUPER;
  bite();
}
[download]

In real-world logic, it's obvious that the AngryDog should still growl before biting when its tail is pulled, not bark.

It's been quite a while since I last used C++, but I talked to a Java junkie friend the last time something like this came up and he confirmed that Java handles it the same as Perl does. I'm pretty sure C++ (and, for that matter, any language that supports polymorphism) would also behave similarly. To do otherwise would render abstract classes/methods pointless. (Derived class overrides the abstract method, base class method calls the abstract method, and... either nothing happens or an exception is thrown unless it calls the derived class's version instead of the base version.)

But, yeah, I do agree that inheritance looks like an obvious candidate, but dragonchild's AUTOLOAD-based solution is surely both the slickest solution and the one which requires the least code to do what you want.