> If lexical variables are the default, then 'strict vars' will be
> totally unnecessary because it will be impossible to forget the 'my'.
Actually, this is what I suggested as well, but was promptly shot down
by Nat and others. The more I think about it, I think I understand why
you *need* the "my". J. David pointed out that lexical scoping has a
"non-Perl" definition:
with lexical scoping a variable lookup starts in the
current block and proceeds outwards according to
the scope in which the block was declared
So, consider this piece of C code:
int myint;
/* time passes */
if ( something ) {
while (1) {
if ( somethingelse ) {
myint = 1;
}
}
}
printf("myint is %d\n", myint);
Now, here's the corresponding Perl code (without strict):
# time passes
if ( something ) {
while (1) {
if ( somethingelse ) {
$myint = 1;
}
}
}
print "myint is $myint\n";
So, if we were to make "lexical variables the default", truly, then the
Perl code above would only define $myint inside the innermost if
statement, meaning that the print statement would say "myint is ".
But the C one works fine. Why? Because myint's been lexically declared!
This is how my() works. When used to declare a variable, it sets the
lexical scope of that variable, saying "anything called '$myint' inside
this current block is the same variable".
Granted, we could also try to do some really fancy stuff with
dynamically determining the scope, making a "best guess" as where it
should end up. Maybe we could scan outwards, and the outermost one we
found by the same name would be the scope of that variable. That doesn't
sound bad. But Tom had a really good analysis here as well:
Python isn't truly block-scoped, but just global-package-function
scoped, a variable without the global keyword belongs to whichever
of those (package global or function local) it appears in. However,
it's highly dodgy, because if used lvaluably, it is implicitly
package
global, but used rvaluably, it is implicitly function local. This
is crazy.
Point is: we're stuck. Any solution that radically changed how we wanted
to declare variable would probably be a big mess and turn a lot of
people off to Perl 6, because it would be obfuscated and hard to debug.
*NOTICE*: I am NOT arguing for turning *any* strictness on by default.
As I've said before, people need to know:
1. What they're doing
2. Why they're doing it
One fact of life with Perl is that many more people are going to write
bad Perl code than C code. Why? TMTOWTDI. It takes years of experience
with Perl to understand the language, just like it takes years of
experience with English to understand how to speak it. We don't expect
babies to be fluent, and we shouldn't expect beginner Perl programmers
to be fluent either. The "problem" here is NOT Perl. It's good
instruction, experience, and thoughtfulness.
Strictness is not the magic bullet that fixes everything and makes
everything better. I've seen plenty of crappy code with massive errors
in logic that use strict and my's correctly throughout.
-Nate
