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

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.

Comment on Re^5: use Ensure -- module to spot undefined stuff Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]