Re^4: use Ensure -- module to spot undefined stuff

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.

Comment on Re^4: use Ensure -- module to spot undefined stuff Select or Download Code

Replies are listed 'Best First'.
Re^5: use Ensure -- module to spot undefined stuff by Fletch (Bishop) on Aug 06, 2008 at 17:18 UTC
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.	[reply] [d/l]
Re^6: use Ensure -- module to spot undefined stuff by gone2015 (Deacon) on Aug 07, 2008 at 00:05 UTC
I don't think that a dynamic language has to be an unnecessarily dangerous one. Accepting that `AUTOLOAD` etc. are extremely useful, does one really have to accept run-time errors with simple subroutines, when a small amount of extra checking could pick up the error at compile-time ? I think the answer is no. But it's not free: it requires the programmer to declare subroutines which aren't going to be defined at compile time. This doesn't prevent the use of the dangerous stuff, it just makes it explicit. (The `Ensure` module uses `no Ensure` for the required declaration.) It's hard to argue against perfection in testing. However, I'd still rather have the compilation system spot the obvious errors for me -- so I can concentrate on the really hard stuff.	[reply] [d/l] [select]