in reply to Re^2: use Ensure -- module to spot undefined stuff
in thread use Ensure -- module to spot undefined stuff

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]

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

Replies are listed 'Best First'.
Re^4: use Ensure -- module to spot undefined stuff
by gone2015 (Deacon) on Aug 06, 2008 at 16:15 UTC

    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.

[reply]
[d/l]
[select]

      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]

        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]

In Section Code Catacombs