it seems its a good habit The safest thing you can do is to stringify $1,$2 when you're not doing assignment using them in an lvalue context.
f("$1")
for ("$1")
\"$1"
| [reply] [Watch: Dir/Any] [d/l] |
The safest thing you can do is to stringify $1,$2 when them in an lvalue context. I'm not sure that is much clearer. perlglossary lists lvalue but not lvalue context, but when you compare context, scalar context and list context, and plug-in lvalue, it doesn't quite work , unless you lookn up expression and then value.
Putting all that together assignment is also lvalue-context, but I wouldn't recommend needlesly quoting $1 in my $one = $1;
So I might rephrase as
When using $1,$2... in an expression ( anything you can legally say in a spot where a value is required ) you should quote to stringify and preserve the current value.
foo("$1") instead of foo($1)
$bar = "$1" + foo(); instead of $bar = "$1" + foo();
No need to quote straight assignment if(m/.../){ $bar = $1; }
| [reply] [Watch: Dir/Any] [d/l] [select] |
lvalue context has nothing to do with scalar/void/list context.
lvalue and lvalue context are not the same thing.
An lvalue context is a context where an expression must produce an lvalue. In contrast, an rvalue context is a context where code may produce an rvalue.
Example of lvalue contexts:
- Sub arguments.
- The arguments to some functions.
- The operand of the reference operator.
- The LHS operand of assignment operators.
- foreach's list.
When using $1,$2... in an expression ( anything you can legally say in a spot where a value is required ) you should quote to stringify and preserve the current value.
No, it's stupid to do $x = "$1";.
...though I admit the lvalue context is not sufficient (e.g. $bar = "$1" + foo();).
| [reply] [Watch: Dir/Any] [d/l] [select] |
| [reply] [Watch: Dir/Any] |