> It was suggested to DWIM when I use my in void context, and not when
> my isn't used in void context. With the above example, such a rule
> would mean '$bar1' is my()ed, and '$bar2' isn't. That's IMO, very hard
> to explain, very hard to bugtrack and totally unexpected. Even if not
> everyone uses it.
well, for the small fraction of people that use it, they probably are
experienced and know to use parens to disambiguate. That's what I do when
I come across something totally unexpected. And anyways:
my $a, $b, $c = @_;
not working is 'very hard to bugtrack and totally unexpected' for a larger
percentage of perl programmers out there.
Anyways, I think this problem goes away if we adopt a suggestion that I
make below.
> > However, I think that:
> >
> > my $a, $b, $c;
> >
> > and
> >
> > my $a, $b, $c = @_;
Hmm. then I have a misunderstanding of what exactly 'void' context is. 'void'
context to me is when you say
$a, $b, $c;
ie: when something is not the lhs of an '='.
> > should work the same and they wouldn't do so if 'void' context was the only
> > criteria used.
>
> Both of the above my()s are in void context.
well, then it works then. cool.
> Also, if I have:
>
> @a = (1 .. 10);
> $a, $b, $c = @_;
How about 'an implicit parens around a set of statements separated by commas
in any context'? This is consistent
$a, $b, $c = $d, $e, $f; # ($a, $b, $c) = ($d, $e, $f);
And if you say something like:
$a, $b, $c == 10, $d == 11
you need to disambiguate the sub-statements by saying
$a, $b, ($c ==10), ($d == 11)
my $a = <STDIN> # DWIM
my $a, $b, $c.
As for your examples:
GetOptions (foo => \(my $foo), bar => \(my $bar))
tie (my $shoe) => $string;
both of these look easier to follow to me, at least.
> $c becomes 10. Should $c become 3 when my is placed before $a?
No, I think in both cases, they should produce '3'.
ok, now back to:
(my $foo1, $bar1) = (my $foo2, $bar2) = ('foo', 'bar');
Works as expected. $foo1, $bar1, $foo2, $bar2 are all 'my'ed.
Ed
