It's a hard nut to crack because of things like AUTOLOAD, Autosplit, and run-time access to class symbol tables. We won't even get into the abomination that is multiple dispatch, because I'm still wrapping it around my brain.

I catch a lot more errors running unit tests on my code than I do running it through the compiler and looking for warnings. If you exercise your code paths sufficiently as bikeNomad suggests, you'd get closer to what you want than the compiler can provide.

It's not exactly what you want, but it's working pretty well for me.

Having been a Smalltalk user for at least 5 years now, one thing that helps in typical Smalltalk environments is their checking of method names when you define new methods. Every time you edit a method, it's recompiled; the compiler does a simple check to see if any of the method names you're using haven't been defined yet. If so, you get a warning. This has helped me detect a lot of typos in my code.

I'm thinking that a similar strategy could be used with Perl, by scanning programs like this:

• For each 'use'd or 'require'd package, make a defined symbol list (easiest way to do this is probably just to use B::Xref).
• Scan your program for method calls (or, more simply, for words, removing all the Perl pre-defined words).
• Make a list of all the method calls (or words) in your program that don't match any of the subroutines defined in your included packages

This is a simple strategy, and it should be easy to implement. Tell me if it works!

I still prefer full testing, though. Have you read anything about Extreme Programming techniques? One of the XP tenets is to write tests FIRST.