Ah, so the question becomes what does this do that B::Lint doesn't do (other than being fatal rather than printing a warning, that is)?

$ perl -MO=Lint -wce 'foo( );'
Nonexistant subroutine 'foo' called at -e line 1
-e syntax OK
[download]

B::Lint only considers main (at least by default), which doesn't quite fit with an Object approach.

As with use strict, I am surprised that there isn't something more built-in to cover the horribly common case of misspelling a subroutine name -- especially as the error can lie dormant in a little used part of one's code !

If use strict covered it, or if B::Lint was easier to use and could be specified within packages, then this module would be redundant....

In the meantime, I've found it useful and the reason for this posting is to see if other people would too.

I think the main problem I have is that you're applying a static / strongly typed mindset ("the compiler should detect this problem beforehand") to a dynamic language.

The reason it's a runtime error and not something strict prevents is because common idioms (AUTOLOAD, Perl's method dispatch mechanism) render static analysis of calls pointless because the answer can't be known in those (again, commonly used) cases until runtime (and even then the answer may change over any given run).

The approach most dynamic languages encourage instead is to have ample tests which cover as much of your code base as possible (especially tests for the corner cases like the "little used part[s]"). Letting strict catch what can be reliably diagnosed statically, while depending on Devel::Cover and an autocompleting editor to guard against runtime problems, seems to me to be a better solution.

But that's just me, of course. . .

The cake is a lie.
The cake is a lie.
The cake is a lie.