in reply to Re^3: To initialise or not to initialise?
in thread To initialise or not to initialise?

There are several ways to do that. Here are two more. 
my ($foo, $bar, $baz) = map "default", 1..3;
$_="default" for my ($foo, $bar, $baz);

[download]
As obscure as the last one is, I'd prefer it over the others if you think that the variable list will expand since you don't have to synchronize the number of variables with a hard-coded constant.

That is, if I wanted to achieve this effect. Which I never have needed to.

Replies are listed 'Best First'.
Re^5: To initialise or not to initialise?
by runrig (Abbot) on Jun 24, 2004 at 23:14 UTC
    $_="default" for my ($foo, $bar, $baz);
    That one surprises me that it works. I thought that the "for" statement modifier was mere syntactic sugar, since that deparses as:
    u2-4.14 $ perl -MO=Deparse ./tst   
foreach $_ (my($foo, $bar, $baz)) {
    $_ = 'default';
}
./tst syntax OK

    [download]
    But if written as a straight for loop (as it deparses to), then the variables are local to the loop. And I could've sworn I tried that once upon a time, and it didn't work...probably won't be the last time I make that mistake :)
[reply]
[d/l]
[select]
      When you loop over a list, the local variable is aliased to each member of the list. If you modify the variable, then you modify the original member of the list as well.
[reply]
        When you loop over a list, the local variable is aliased to each member of the list.

        Yes, I got that part. The part that surprises me is that B::Deparse deparses it to something that doesn't work, and I always assumed that the deparsing was correct. Consider:

        use strict;
use warnings;
foreach $_ (my ($foo, $bar, $baz)) {
  $_ = "default";
}
print "$foo\n";

        [download]
        This code doesn't run, and it is what I mistakenly assumed your code was the equivalent of (minus the use's and print).
[reply]
[d/l]

      Using my with a modifier is skating on thin ice. While it works on the right side of the for it does bizarre (or at least counterintuitive) things on the left side. In an if the behaviour verges on the undefined (yes i know all about the static var effect.)

      The fact is however that B::Deparse has long gotten the scoping effects of a for modifier wrong. Consider: 

      D:\Development>perl -MO=Deparse -e "my $x=$_ for 1..10;"
foreach $_ (1 .. 10) {
    my $x = $_;
}
-e syntax OK

      [download]

      The $x is not scoped to the for loop. Its scoped to the container of the for loop. Its also not so great at the scoping effects of the if modifier either: 

      D:\Development>perl -MO=Deparse -e "my $x=1 if 0; my $y=1 if 1;"
'???';
my $y = 1;
-e syntax OK

      [download]

      Re: Re: 'my' headache...Why Deparse is Wrong. and Regarding B::Deparse both discuss errors like this.

      The moral of the story is essentially don't trust deparse. :-) Its a useful tool, but blindly assuming it is correct will just muddle your brain.

      Btw, a little trick:

      Read more... (779 Bytes)

      Which even if it shameless advertising shows why use()ing Data::Dump::Streamer when debugging stuff can be a lot nicer than the other tools around.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom