On Fri, 31 Mar 2000 15:29:06 -0800 [EMAIL PROTECTED] (Peter Scott) wrote:
* At 04:17 PM 3/31/00 -0700, Joseph N. Hall wrote:
* >* ObPerl: How to explain to a class of complete novices why parens are needed
* >* in my ($x, $y); but if you follow a general rule of "put parens in
* >* everywhere until you figure out where you can leave them out" you get
* >* benign warnings "foo(...) interpreted as function"...
* >
* >Because my acts as a "list modifier." The semantics are the same whether
* >or not you have the my:
* >
* > $a, $b = $x, $y; # not too good
* > my $a, $b = $x, $y; # not too good either
* >
* > ($a, $b) = ($x, $y);
* > my ($a, $b) = ($x, $y);
* >
* >No matter what you do, the = operator always has higher precedence
* >than the comma operator. Whether there's a my involved doesn't affect
* >that.
*
* Yes, but I was talking about the case where there is no assignment, just
*
* my ($x, $y);
*
* Novice sees this and thinks, "Those parens must be unnecessary for the same
* reason that they are in "print (args);", no? Is 'my' a function?...
* (checks perlfunc, there it is)... okay" (boom, subtle error).
*
Well, I'd like to say it's the same reason that
sin $x, $y
means
sin($x), $y
but it's not, really. There's magic involved in what happens to the
stuff to the right of my. So it's "just that way."
The rules are simple. If you're using my on a single variable all by itself,
you don't need parens. If you're using my on a list of variables all by
themselves, you need parens.
If you're using my in an assignment, whether there are parens on the left
determines whether the assignment is scalar or list.
Well, fairly simple anyway.
-joseph
