The problem with lexical variables being made default, in earnest, is
simple, and error-prone:
code;
if ( condition )
{ more code;
$x = 'did then'';
} else
{ more code;
$x = 'did else';
}
print $x;
What lexical scope should $x be _implicitly_ declared in? Maybe, just
maybe, we need a my $x at the top to tell us it is outside the scope of the
first reference. Otherwise we get three different lexical variables, and an
undefined value warning at run time.
Nathan Wiger wrote:
> > I have retained the title of "Lexical variables made default,"
> > because I still feel that that is the primary purpose of this change
>
> First off, I think this is a great idea in principle. However, I don't
> think it goes nearly far enough in the implementation. I'd like to
> propose something radical.
>
> Consider code like this, which is not uncommon:
>
> use strict;
> my $var1 = 'some val';
> my $var2 = 'some other val';
>
> sub mysub {
> my($arg1, $arg2) = @_;
> (my $result = $arg1) =~ s/some/every/g;
> return ($result, $arg2);
> }
>
> my @stuff = mysub($var1, $var2);
>
> You get the idea. Dang there's a lot of my()'s in there! The only thing
> I see this RFC changing is the need for the "use strict" statement.
> However, the code is still littered with what I would argue are
> "useless" my()'s that serve as workarounds for a fundamental flaw in the
> langauge: all variables are global by default.
>
> Before you write me back and claim heresy, let me explain what I mean.
> When the usage of Perl was basically only as "shell scripting on
> steroids", all global variables worked fine. However, as Perl 5 became
> more and more powerful and extensible, and classes and OOP became
> mainstays, this no longer worked. So, my() is now used pervasively to
> manually impose much needed compartmentalization of code.
>
> I argue we should fundamentally shift this thinking in Perl 6. Let's
> truly have "lexical variables made default". Let's change the above code
> to:
>
> #use strict; # unneeded, now implied
> $var1 = 'some val'; # my() now default
> $var2 = 'some other val';
>
> sub mysub {
> ($arg1, $arg2) = @_;
> ($result = $arg1) =~ s/some/every/g;
> return ($result, $arg2);
> }
>
> @stuff = mysub($var1, $var2);
>
> One basic rule of user interface is that "if something's easy and
> repetitive, have the computer do it". I would argue my() is such a
> beast. I propose these changes:
>
> 1. "use strict" as default
> 2. my() the default scope of vars
>
> If Perl 6 is going to be successful and hailed (as I'm sure we all hope
> it is), I think it has to offer some clear advantages that make things
> easier. Consider which of these sounds more like a benefit:
>
> 1. setting "use strict" on by default, forcing
> users to formally declare all their variables
> as my()'s
>
> 2. making it so that they don't have to anymore
>
> I would argue that (1) is a burden, but (2) is a benefit. Doing it this
> way doesn't break scripts either - in fact it makes it easier to avoid
> accidental errors, even in "quick-and-dirty" scripting:
>
> sub square {
> ($x) = @_;
> $x *= $x;
> }
> $x = 2;
> $ans = square($x);
> print "$x squared is: $ans\n"; # uh-oh
>
> One could argue that "you shouldn't make this mistake", but c'mon. We're
> human, and I'm sure everyone on this list has done this. Let's make Perl
> 6 do the hard work for us. :-) Moreover, we can leave my() just as-is,
> so if someone wants to explicitly use it for clarity they're welcome to.
>
> -Nate
>
> P.S. I know that square() example is trite, but it's the best I could do
> in 30 seconds. :-)
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
