go ahead... be a heretic | |
PerlMonks |
Re^2: On quoting the lhs of '=>'by rovf (Priest) |
on Jul 09, 2008 at 11:54 UTC ( [id://696431]=note: print w/replies, xml ) | Need Help?? |
Thank you for pointing out Readonly. I will certainly have a look at it, and using & is a good suggestion too. However, the quote from perldoc, Unary "+" has no effect whatsoever, even on strings. does IMHO not explain the observed behaviour. Note that the decision of whether or not the lhs of => is taken as expression, depends (according to the docs) on whether or not it is a bareword. This is a purely syntactical issue and does not take into account what an operator does. We have +BIRD to the left of =>, and this is certainly not a bareword. If your interpretation of the perldoc is correct, the compiler's reasoning would go along the following line: "Hmmmm, we have +BIRD. I have no idea what BIRD is (haven't decided yet), but no matter what it is, + won't change it anyway, so just throw it away. This leaves us now with BIRD=>...., so now to the left of => we have a bareword; OK, let's quote it". I feel that this would be a very strange approach to compiling. Kind of: Evaluating unary + very early (because it is trivial to evaluate), and keep the other operators for later (because their interpretation depends on the context). Update: I would like to add that an unary + does work when it comes to access the element of a hash. For example, $x->{+BIRD}substitutes the constant BIRD. If your interpretation of perldoc would be correct, this expression should be treated equivalent to $x->{BIRD}, but (and IMO correctly), only in the latter case is BIRD taken as the string BIRD.
-- Ronald Fischer <ynnor@mm.st>
In Section
Seekers of Perl Wisdom
|
|