Answer.

Background:

OOP in Perl is implemented based on packages and reference binding through the bless function. Inheritance is achieved through the @ISA array, which automatically determines which packages Perl will search for methods. The search mechanism implements the so-called MRO (method resolution order).

Problem:

Chaotic management of the @ISA array and the use of SUPER without understanding the method search order often leads to errors, double calls, or the inability to override the desired functionality. The use of AUTOLOAD requires control to avoid traps of infinite search loops.

Solution:

Use explicit declaration of @ISA in all inherited packages.
For calling parent methods, correctly refer to SUPER and keep in mind that it is not always directly the "parent", but the first found match at the top of the ISA chain.
Use AUTOLOAD only for specific tasks (e.g., dynamic getters/setters).

Code example:

package Animal;
sub speak { print "Animal speaks
"; }

package Dog;
our @ISA = qw(Animal);
sub speak { 
   print "Dog barks! ";
   shift->SUPER::speak(); # call parent method
}

my $dog = bless {}, 'Dog';
$dog->speak;

Key features:

@ISA defines the method search chain.
SUPER searches for method invocation at the top of the chain, not just at the immediate parent.
AUTOLOAD is needed to catch missing methods but requires caution.

Trick questions.

If there are multiple parent packages in the inheritance chain with the same method names, which will be called?

The search is performed left to right (in the order of declaration in @ISA), and the first found method is called.

What happens if a certain method is absent in the entire inheritance tree, and AUTOLOAD is implemented only in one of the parents?

Perl will call AUTOLOAD only for the class where it is found first in the method search chain. Other AUTOLOAD implementations will not be triggered if they do not occur earlier in @ISA.

Can the chain lookup order of a method be changed on the fly?

Technically, the @ISA array can be modified at runtime, but this leads to fragility and hard-to-trace errors. This approach is recommended only for specific cases.

Common mistakes and anti-patterns

Confusing SUPER with a direct parent call — SUPER searches up the entire chain, not just in the first parent.
Dynamically modifying @ISA without a strict reason.
Using AUTOLOAD for mass delegation without explicit filtering.

Real-life examples

Negative case

Multiple parent classes are used with the same method names, their order in @ISA changes unpredictably by hand, methods call SUPER, leading to infinite recursion.

Pros:

Flexibility of composition.
Quick prototyping possible.

Cons:

Difficult to predict the outcome of the entire tree.
Repeated method calls and recursive traps.
Non-obvious behavior of SUPER.

Positive case

Modifications only through explicit declaration of @ISA, and when multiple inheritance is needed — using specialized modules like mro::Concise or Class::C3.