By having the linter make the giant assumption that all subs are methods, that tells you a bit about $self, but not enough. It only helps determine that cases such as the following aren't problems:
{ package Base; sub x { ... } } { package Child; our @ISA = 'Base'; sub y { shift->x } }
However, it doesn't help determine that something is a problem. For example, is there a problem in the following?
package Package; sub y { shift->x }
No, turns out package Package is just a role:
{ package SomeRole; # Implementor must provide y sub y { shift->x } } { package Class; our @ISA = 'SomeRole'; sub x { ... } }
But that's not the real test. How often do you call a child method that doesn't exist? I expect the majority of problems to be in code such as the following:
orsub some_method { my ($self, $arg) = @_ ... $arg->other_method(); ... }
sub some_method { my ($self) = @_ ... $self->attribute->other_method(); ... }
The linter knows absolutely nothing about the class or object whose method other_method is being called, so it has no idea if other_method exists for that class or object.
In reply to Re^3: linting for undefined object methods
by ikegami
in thread linting for undefined object methods
by aespen
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |