"Lorne Easton" <[EMAIL PROTECTED]> writes:
> I don't understand this line..
>
> $session = Net::SNMP->session(-hostname => "10.0.0.100", -community =>
> "public");
I'd align it differently for readability:
$session = Net::SNMP->session(-hostname => "10.0.0.100",
-community => "public");
=> is the stringifying-coma it's just like a coma, but it
forces its LHS to be a string. It's used for readability,
and is produces this equivalent code.
$session = Net::SNMP->session("-hostname" , "10.0.0.100",
"-community", "public");
But see how much easier it reads if the line is long or
isn't pretty-formatted? (Ignore the string/integer
difference of the LHS in the following example. I chose
numbers to make it look confusing without the => operator.)
%squares = (1, 1, 2, 4, 3, 9, 4, 16, 5, 25, 6, 36, 7, 49, 8, 64);
%squares = (1 => 1, 2 => 4, 3 => 9, 4 => 16, 5 => 25, 6 => 36, 7 => 49, 8 => 64);
Of course, I like to run 'em down the page instead of across.
%aphorism = {
roses => "red",
violets => "blue"
suger => "sweet"
sex => "won't rot your teeth"
};
> ($session, $error) = Net::SNMP->session(
> -hostname => shift || '10.0.0.100',
use and consume first value in @_ if there is one
else use default
> -community => shift || 'public',
use and consume first value in @_ if there is one
else use default
> -port => shift || 161
use and consume first value in @_ if there is one
else use default
> );
It's taking advantage of the short-circit operation of the
binary logical-or operator (||). If the LHS is true (which
it will be if there's any(defined)thing in @_, the implicit
argument to shift), that becomes the value of the binary
operation and evaluation stops. If the LHS is not true, the
RHS is evaluated, and that becomes the value of the binary
operation.
> I thought it was used like.
>
> open(INPUT,"<$file") || die "Error";
It is. See above explanation of short-circuit binary
logical-or. When spoken as english, it makes sense: "Open
a file handle named INPUT as input from $file or die".
Simply: open or die.
> being equivalent of:
>
> if !(open(INPUT,"<$file") { die "Error; }
You are correct.
However, I prefer to use "or" due to a subtle precedence
issue. I worked it out in my head a while ago. It took me
about 1/2 hour to decide why "or" was better than "||".
They have different precedence, and therefore will bind
differently when surrounded by operators whose precedence is
between theirs. See the code below.
[[Style pointer: $! is defined if open fails, so it's nice
to pass it along to the end user. Did it fail because the
file didn't exist, or because of bad permissions, or because
too many files are already open....? That's interesting
information that you can pass along for free. And use a
better phrase than "Error". When death is involved
(i.e. die) you want all the information you can get!!!]]
# ================
With parenthesis, they're equivalent.
open(INPUT, "<$file") || die "Cannot open input file: $!"; # OK
open(INPUT, "<$file") or die "Cannot open input file: $!"; # Preferred
open(INPUT, "<$file")
or die "Cannot open input file: $!"; # Preferred - reformatted.
# ================
Without parenthesis, there's a precedence problem.
open INPUT, "<$file" or die "Cannot open input file: $!"; # OK
open INPUT, "<$file"
or die "Cannot open input file: $!"; # OK - reformatted
open(INPUT, "<$file") or die "Cannot open input file: $!"; # OK - equivalent
open(INPUT, "<$file")
or die "Cannot open input file: $!"; # OK - equivalent reformatted
# ================
open INPUT, "<$file" || die "Cannot open input file: $!"; # BAD!!!
open INPUT,
("<$file" || die "Cannot open input file: $!"); # BAD!!! -- reformatted
open INPUT, ("<$file" || die "Cannot open input file: $!"); # BAD!!! - equivalent
open INPUT,
("<$file" || die "Cannot open input file: $!"); # BAD!!! - equivalent reformatted
open INPUT, "<$file"; # BAD - What gets executed!
# ================
die never hapens, even if the open fails!!!!!!!!
Why? Higher precedence of "||" binds more tightly than ",".
Therefore, the second argument to open degenerates to:
"string" || die
Since any string (in the specific case "<$file") is true, it
becomes the value of the expression *without* evaluating the
RHS.
In case you didn't catch the all that, I've come up with a
simple rule. I've been programming in Perl since version 4.
It took me years to wrangle up the argument I just presented
but this little ditty is easy to remember. It's what I
remember when I'm coding. I don't have time or gray matter
to spare to remember precedence tables.
================
Use the "word flavor" (i.e. "or") with words (like die):
open HANDLE, "file" or die "why";
Use the "symbol flavor" (i.e. "||") with symbols (like "<", "<="):
if ($x < 7 || $y <= 42 || $z > 99)
================
It kinda' parallels another simple rule I have for use in
comparison operators:
Use the "word flavor" (i.e. "le") with words:
if ("apple" le "bannana")
Use the "symbol flavor" (i.e. "<=") with symbols (a stretch to mean "numbers")
if (7 <= 42)
================
And of course, with respect to parenthesis: when in doubt,
whip 'em out. Extra parens never hurt. Missing ones
often do.
--
Michael R. Wolf All mammals learn by playing!
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
