in reply to Overriding methods and Inheritance

This is one of those cases where inheritance isn't necessarily the right way to do things, even though it seems ideally suited. What you really want is delegation, specifically you want to decorate the ExceptionThrowingModule with your own module. So, something like so:
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__
There's more you'd have to do in order to make sure you play properly with overload and others. But, that's the gist of it. And, the runtime cost is quite minimal, probably on the order of 1-2%. And, you're very loosely couple with OtherModule, meaning that as OtherModule changes, you don't have to change with it.

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?

Replies are listed 'Best First'.
Re^2: Overriding methods and Inheritance
by bamaindk (Initiate) on Jan 08, 2008 at 09:29 UTC
    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?