Nathan Wiger <[EMAIL PROTECTED]> writes:
>> 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 imp
>I've heard "internal consistency" bandied about a lot. I think
>auto-my()ing variables in these sub declarations is a bad idea.
>What if you DON'T want them to be my()'ed? Do we have to add a global()
>keyword?
That's what Python requires. Keeping in mind that Python isn't
truly block-scoped,
Johan Vromans wrote:
>
> What would be the semantics if 'my' were left out? Would it be
> equivalent to:
>
> sub whois ($) {
> local($user) = @_;
> }
No. I'd say it should inherit the default global scope. This is
*consistent* within Perl. Here's the choices as I see it:
1.
Tom Christiansen said:
> >This doesn't fix the problem of:
> >{
> > $somevar = 0;
> > $someVar++; # oops, wrong case!
> >}
> >Forcing 'my' by default allows these errors to be caught.
>
> How so?
>
If the default is to force 'my' to create a lexical, rather than providing a
default lexical scope
>This doesn't fix the problem of:
>{
> $somevar = 0;
> $someVar++; # oops, wrong case!
>}
>Forcing 'my' by default allows these errors to be caught.
How so?
--tom
Nathan Wiger <[EMAIL PROTECTED]> writes:
> So will these be "automatically-my()ed"? Or will you have to say:
>
>sub whois (my $user) {
># ...
>}
>
> This seems more consistent (but there's that dang my() again!) :-)
What would be the semantics if 'my' were left out? Would it be
Nathan Wiger <[EMAIL PROTECTED]> writes:
> > You've taken the wrong approach. If you're writing a big program then
> > there should be *no* default scope. Any variable access is an error
> > unless that variable was my()ed or our()ed. That's basically what
> > 'strict' gives us.
>
> Fair enou
Tom Christiansen wrote:
>
> > I have retained the title of "Lexical variables made default,"
> >because I still feel that that is the primary purpose of this change,
> >meaning that in future Perl documentation (books, manpages, classes (I
> >hope)) new Perl users will first be presented with va
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.
> Besides, named arguments will solve this (in fewer chars even :-)...
>
>$user = 'nwiger';
>sub whois ($user) {
># ...
>}
>
> Damian
Great point. I'll "settle" for that (it's what I'm looking for anyways).
:-)
So will these be "automatically-my()ed"? Or wil
> However, I do think there's something to be said for a "quick-and-dirty"
> script out of the box that can distinguish between sub{} vars and other
> vars ala C:
>
>$user = 'nwiger';
>sub whois {
>($user) = @_;# different var
># ...
>}
> You've taken the wrong approach. If you're writing a big program then
> there should be *no* default scope. Any variable access is an error
> unless that variable was my()ed or our()ed. That's basically what
> 'strict' gives us.
Fair enough. I've heard several good analyses against my idea,
Nathan Wiger writes:
> I argue we should fundamentally shift this thinking in Perl 6. Let's
> truly have "lexical variables made default".
Ugh. Baby, bathwater.
If I'm writing a big program, then I want to have to declare all
variables so that Perl can catch errors for me. That's the big
benef
Nathan Wiger said:
> > 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.
>
> 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.
You're right, great point. T
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
> 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 rad
> I have retained the title of "Lexical variables made default,"
>because I still feel that that is the primary purpose of this change,
>meaning that in future Perl documentation (books, manpages, classes (I
>hope)) new Perl users will first be presented with variables declared
>as lexicals with
John Tobey wrote:
>
> "J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> > Thanks for the feedback, everyone. I now believe that what we
> > really want is what so many have suggested, i.e., making strict 'vars'
> > the default (in essence, at least).
>
> Sorry if this was mentioned already.
"J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> Thanks for the feedback, everyone. I now believe that what we
> really want is what so many have suggested, i.e., making strict 'vars'
> the default (in essence, at least).
Sorry if this was mentioned already. If this change is adopted, I
wou
Thanks for the feedback, everyone. I now believe that what we
really want is what so many have suggested, i.e., making strict 'vars'
the default (in essence, at least).
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of thi
21 matches
Mail list logo
