Re: scope of "use strict"? (needed: "superstrict")

[etcshadow]

Unfortunately, this is not going to help you out. If a module was written without using strict, adding strictures to it, after the fact, will most likely cause it to completely stop working.

Take CGI.pm for example. It doesn't use strict, and it does work. If you download it from CPAN, and add "use strict;" to the top of it, it'll be all compiler errors and completely stop working.

Strictures are a tool for writing code, not for debugging code. Granted, code written with strictures is going to be easier to debug... but code written without strictures cannot be debugged by applying strictures. If anything, it will be "bugged" by doing so.

[ikegami]

Goind point. What might be off service are warnings. Using -w on the command line will turn on warning for the script AND for modules (unless they explicitely turn them off).

[argv]

Using -w on the command line will turn on warning for the script AND for modules (unless they explicitely turn them off).

Geez--call me stupid... but this doesn't seem to do it for me. I've got a simple perl module Foo.pm that exports a single function, foobar()

Package Foo;
require Exporter;

our @ISA        = qw(Exporter);
our @EXPORT     = qw($foo foobar);

$foo = "bar";

sub foobar
{
    $blah = "hi";
    print "$foo $blah\n";
}

1;

I wrote a perl script (foo.pl) that imports Foo.pm:

#!/usr/bin/perl
use Foo qw(foobar);
$bar = "hi";    
foobar();

I inserted stuff in both the .pl and the .pm files that should generate warnings to test this. (Running foo.pl with no warnings is clean, expectedly.) So, I run:

perl -w foo.pl

and sure enough, I get a warning in my foo.pl script, but I do not get a warning for the $blah = "hi"; line in Foo.pm. If I add "use warnings;" to the top of Foo.pm as well, then yes, I do get a warning for Foo.pm. But, this goes against what you said: that "perl -w" should propagate the warnings to all the modules... what am I missing?

dan

ps. On another note entirely, "use strict;" in the module complains about $bar, which is exported. This is how the doc says to do it, and I see no other resource that says differently.

[rev_1318]

Why would you expect a warning from $blah = "hi";? There is nothing wrong with your package (except the Package statement, which should read package). The only warning you should get (and do get with warnings turned on) is:

Name "main::bar" used only once: possible typo...

which is correct.

[ikegami]

(Sorry for not getting to you sooner; I was on vacation.)

Your module doesn't give warnings because there's nothing to warn. Even if you added use warnings to the module, there still wouldn't be any warnings. Here's an example of -w affecting modules:

>type Foo.pm
package Foo;

sub foobar {
   print undef;
}

1;

>type foo.pl
use Foo;
Foo::foobar();

>perl -w foo.pl
Use of uninitialized value in print at Foo.pm line 4.

[argv]

Granted, code written with strictures is going to be easier to debug...

Indeed, and therein lies my objective. My goal isn't to run the program or even "debug" it, per se. It's to look for specific kinds of error messages that may lead down a very specific path that may pre-empty looking in the wrong direction (for a potentially long time).

[etcshadow]

You're missing my point. If the code was written without strictures, you cannot add them without rewriting the code. You're just as likely to introduce new bugs in doing so.

Take this overly simple example:

sub blarg {
    $i = $i+1;
    return $i;
}

Now, if you think "there's somethng wrong with this code, I'm going to fix it by adding strictures," then your first step would be:

use strict;
sub blarg {
    $i = $i+1;
    return $i;
}

Now this will give you errors (use of undefined variable $i). AHA! you say, I'll fix this by declaring $i at the scope at which it is used:

use strict;
sub blarg {
    my $i = $i+1;
    return $i;
}

Problem solved, strict warnings are gone. Only now your code is completely and totally broken, because little did you know that blarg() was a sequence generator. $i should have been declared at a broader scope than you did. Notice that your change was not syntactically incorrect, but it was semantically incorrect.

Another option would be just to declare every variable used in the entire program at as wide a scope as possible, but that would completely defeat the purpose of strictures, all together.

Last is to try to write something which goes through and adds in a my $var at the "right" scope. The problem with that, however, is that in the general case it is equivalent to The Halting Problem, i.e., writing a program that can analyze and understand the execution of another program, and it is provably IMPOSSIBLE. (Before anyone jumps on me about that being a false statement, about run-time versus structure, I just have one thing to say to you: eval.)

In the end, code written with strictures is DIFFERENT CODE than code written without strictures. Turning strictures on in code that was written without them will just make things worse (unless you plan on REWRITING the code, COMPLETELY). What you're asking for is tantamount to something like: "Well I think that Java is easier to debug than Perl, so I'll take my perl code and run it through a java compiler." All it will do is produce red-herring errors, and tell you nothing about why your code is not doing what you want. Sorry.

[ihb]

Actually, the problem isn't solved after the my is added. The $i on the RHS in the assignment isn't declared. You'd more likely "fix" it (incorrectly) by adding my $i; at the very beginning of the subroutine.

ihb

[argv]

Problem solved, strict warnings are gone. Only now your code is completely and totally broken...

And you're missing my point. It's NOT to debug anything, or to change anything, or even to run the code at all. My goal is to simply examine the output that strict would generate. For example, if the main program has a "use of undefined variable" error, and I suspect that it's because of this that some other module may be stepping on it, there may be some value in finding what that other module is, and see if what it's doing accounts for the types of incorrect data results that may be generated. For example, if I am using a variable "$total" that was not defined, but when the program runs, I'm getting values from $total that don't seem right, it may be useful to know who else may be stepping on it and to see why. Sure, it may not have anything to do with MY $total... or does it? Perhaps I should have been importing $total instead of writing my own?

Granted, this was a simple example, but in a bigger and far more involved and intricate system, this kind of sleuthing just may be what the doctor ordered.

One cannot make sweeping statements like "it's pointless to force use strict on other modules if the bug lies in your own code" because context is very important here. Being aware of your neighborhood is just as important as taking care of your own backyard.