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

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;
}
[download]

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;
}
[download]

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;
}
[download]

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.

------------
:Wq
Not an editor command: Wq
[download]

Comment on Re^3: scope of "use strict"? (needed: "superstrict") Select or Download Code

Replies are listed 'Best First'.
Re^4: scope of "use strict"? (needed: "superstrict") by ihb (Deacon) on Jul 08, 2005 at 00:50 UTC
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` See perltoc if you don't know which perldoc to read!	[reply] [d/l] [select]
Re^4: scope of "use strict"? (needed: "superstrict") by argv (Pilgrim) on Jul 08, 2005 at 00:16 UTC
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. Dan Heller http://www.danheller.com	[reply] [d/l]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks