Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Monks, 
Caller.pl:
use strict;
use test;
if (a != b)
{
  est::Log("There is an issue")
}

[download]
In the above sample code, I misspelled the call to the Log function in the test module and I couldn't figure that out during design time. I know I am using "strict" but it looks like it is not working. Is there a module that could help me to identify the invalid function calls during design time rather than run time. Thanks for your help Kris

Replies are listed 'Best First'.
Re: How to identify incorrect subroutine calls in a perl program
by Fletch (Bishop) on May 15, 2006 at 17:29 UTC

    You can't really. Perl being as dynamic as it is, there's nothing to prevent a subroutine Log in the package est being defined at run-time that it could know of by static analysis.

[reply]
[d/l]
[select]
      Hello My apologies, I dont think the question I asked was what I intended to ask. The issue is, instead of saying "test::Log" in the code, I said, "est::Log". So you think there is no perl module that could help me to figure out whether the "est::Log" (where there is no "est" module) is valid or not, when I say "perl -c caller.pl" ? Please advise
[reply]

        You can't tell if it's invalid; at best you could say that it might be invalid. 

        if( $phase_of_moon eq 'gibbous'
    or $customer_account->balance > 867_5309 ) { 
  eval qq{package est; sub Log { print LOG "Awooooooo: ", @_ }};
}

        [download]

        Is it valid now? If you looked at the symbol table, you'd think no. But will it be valid the next time the program's run? How about the 2034th time you run it?

        Granted you possibly could write something to grobble over the parse tree and compare that with defined subs from the symbol table and then warns for things it doesn't see there. I don't know of anything that does that offhand though.

        And really I don't know if there'd be much call for it. Presumably you hit this error once, corrected it, and moved on. Just like any other run-time error in your code; the only difference from more conventional syntax errors is that you hit it at runtime rather than at perl -wc foo.plx time. Such is the price you pay for flexibility.

        Update: And the unit testing aficionados would chime in that you of course have tests which exercise all of the paths through your code so something would hit the offending code right out of the gate. :)

        Update: Added something to "Granted ..." to hopefully clear up wording.

[reply]
[d/l]
[select]
Re: How to identify incorrect subroutine calls in a perl program
by dragonchild (Archbishop) on May 15, 2006 at 18:01 UTC
    Don't do things like that. You're bypassing the features built-in with strict. Instead of using test::Log(), have test export the Log() function. Then, strict will complain about a bareword, indicating the subroutine isn't defined.
    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      >perl -c -we "use strict; Log('There is an issue')"
-e syntax OK

      [download]

      What complaint about a bareword?

[reply]
[d/l]

        Calls without parens need to go to pre declared subs, hence a compile time error.

         perl -c -we" use strict; Log 'There is an issue'"
String found where operator expected at -e line 1, near "Log 'There is
+ an issue'"
        (Do you need to predeclare Log?)

        [download]

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

[reply]
[d/l]

Back to Seekers of Perl Wisdom