[32938] in Perl-Users-Digest
Perl-Users Digest, Issue: 4214 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 18 00:08:37 2014
Date: Sat, 17 May 2014 15:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 17 May 2014 Volume: 11 Number: 4214
Today's topics:
A question about grep <liyaoxinchifan@gmail.com>
Re: A question about grep <m@rtij.nl.invlalid>
Re: A question about grep <rweikusat@mobileactivedefense.com>
Re: A question about grep <thepoet@a-za-z0-9.de>
Re: A question about grep <hjp-usenet3@hjp.at>
Re: A question about grep <liyaoxinchifan@gmail.com>
Re: Help with an operator precedence (?) puzzle <derykus@gmail.com>
Re: Help with an operator precedence (?) puzzle (Tim McDaniel)
Re: Help with an operator precedence (?) puzzle <derykus@gmail.com>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <johnblack@nospam.com>
Re: Help with an operator precedence (?) puzzle <No-Spam@deezee.org>
Re: Help with an operator precedence (?) puzzle <jurgenex@hotmail.com>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <derykus@gmail.com>
Re: Help with an operator precedence (?) puzzle <hjp-usenet3@hjp.at>
Re: Help with an operator precedence (?) puzzle <derykus@gmail.com>
Re: Help with an operator precedence (?) puzzle <m@rtij.nl.invlalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 15 May 2014 23:27:36 -0700 (PDT)
From: Martin Lee <liyaoxinchifan@gmail.com>
Subject: A question about grep
Message-Id: <24b771d4-759c-41db-bbf1-eb28814cf0a8@googlegroups.com>
I read Intermediate Perl today, and I found a piece of code that is:
use HTTP::SimpleLinkChecker qw(check_link);
my @good_links = grep {
check_link( $_ );
! $HTTP::SimpleLinkChecker::ERROR;
} @links;
and I modify this code , like this:
use HTTP::SimpleLinkChecker qw(check_link);
@links = ("http://www.google.com", "http://www.facebook.com", "http://mcnvakdlectter.com")
my @good_links = grep {
check_link( $_ );
! $HTTP::SimpleLinkChecker::ERROR;
} @links;
print "$_\n" for @good_links;
the "mcnvakdlectter.com" is a wrong url, but I get this when I execute this code:
http://www.google.com
http://www.facebook.com
http://mcnvakdlectter.com
I refer to the usage of HTTP::SimpleLinkChecker, this module can get the HTTP response code, I test with http://mcnvakdlectter.com and it return 500, but I
don't know why this url is in @good_links , it's a broken websit!!
PS:
Could you tell me the mean of "! $HTTP::SimpleLinkChecker::ERROR;" in the last code? :)
Thank you very much!
------------------------------
Date: Fri, 16 May 2014 09:57:29 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: A question about grep
Message-Id: <90tg4b-cgv.ln1@news.rtij.nl>
On Thu, 15 May 2014 23:27:36 -0700, Martin Lee wrote:
> I read Intermediate Perl today, and I found a piece of code that is:
>
Example does not use shebang, use strict and use warnings? Bad book!
> use HTTP::SimpleLinkChecker qw(check_link);
> my @good_links = grep {
> check_link( $_ );
> ! $HTTP::SimpleLinkChecker::ERROR;
> } @links;
>
> and I modify this code , like this:
>
> use HTTP::SimpleLinkChecker qw(check_link);
> @links = ("http://www.google.com", "http://www.facebook.com",
Missing 'my';
> "http://mcnvakdlectter.com")
Missing ';'
> my @good_links = grep {
> check_link( $_ );
> ! $HTTP::SimpleLinkChecker::ERROR;
> } @links;
> print "$_\n" for @good_links;
>
> the "mcnvakdlectter.com" is a wrong url, but I get this when I execute
> this code:
>
> http://www.google.com http://www.facebook.com http://mcnvakdlectter.com
>
> I refer to the usage of HTTP::SimpleLinkChecker, this module can get the
> HTTP response code, I test with http://mcnvakdlectter.com and it return
> 500, but I don't know why this url is in @good_links , it's a broken
> websit!!
>
> PS:
> Could you tell me the mean of "! $HTTP::SimpleLinkChecker::ERROR;" in
> the last code? :)
That variable is documented as a string, '!' is not. 'Not' some string is
not well documented, but seems to return an empty string if the string is
not empty and 1 if the string is empty.
It seems to me that this ERROR variable is empty, even though that site
returns a 500 error. Possibly it contains some string the server returns,
which is empty in this case. Try to add a print statement with
$HTTP::SimpleLinkChecker::ERROR to see what happens exactly.
However, following the documentation for SimpleLinkChecker, you should
write it like this:
#!/usr/bin/perl
use strict;
use warnings;
use HTTP::SimpleLinkChecker qw(check_link);
my @links = ("http://www.google.com",
"http://www.facebook.com",
"http://mcnvakdlectter.com");
my @good_links = grep {
defined check_link( $_ );
} @links;
print "$_\n" for @good_links;
The last can be even be boiled down to:
print "$_\n" for grep defined(check_link($_)), @links;
But that is a matter of taste, when learning Perl, it's better not to be
overly smart and terse.
I understand this is an example of grep, but the required functionality
could just as well be achieved with
for my $link (@links) {
print "$link\n" if defined check_link($link);
}
HTH,
M4
------------------------------
Date: Fri, 16 May 2014 11:57:11 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: A question about grep
Message-Id: <87wqdmxa7s.fsf@sable.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Thu, 15 May 2014 23:27:36 -0700, Martin Lee wrote:
[...]
>> PS:
>> Could you tell me the mean of "! $HTTP::SimpleLinkChecker::ERROR;" in
>> the last code? :)
>
> That variable is documented as a string, '!' is not. 'Not' some string is
> not well documented, but seems to return an empty string if the string is
> not empty and 1 if the string is empty.
! is documented as 'returns the logical negation of its right operand'
and perlsyn(1) states that
Truth and Falsehood
The number 0, the strings '0' and '', the empty list "()", and
"undef" are all false in a boolean context. All other values are
true. Negation of a true value by "!" or "not" returns a special
false value. When evaluated as a string it is treated as '', but
as a number, it is treated as 0.
How's that "not well documented"?
------------------------------
Date: Fri, 16 May 2014 13:07:32 +0200
From: Chris Winter <thepoet@a-za-z0-9.de>
Subject: Re: A question about grep
Message-Id: <Ujmdv.18991$p14.11764@fx09.fr7>
Am 16.05.2014 09:57, schrieb Martijn Lievaart:
> It seems to me that this ERROR variable is empty, even though that site
> returns a 500 error. Possibly it contains some string the server returns,
> which is empty in this case. Try to add a print statement with
> $HTTP::SimpleLinkChecker::ERROR to see what happens exactly.
>
> However, following the documentation for SimpleLinkChecker, you should
> write it like this:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use HTTP::SimpleLinkChecker qw(check_link);
>
> my @links = ("http://www.google.com",
> "http://www.facebook.com",
> "http://mcnvakdlectter.com");
>
> my @good_links = grep {
> defined check_link( $_ );
> } @links;
> print "$_\n" for @good_links;
This doesn't do what the names imply either. An undefined return
code of check_link signals an unpredicted error in HTTP::UserAgent,
and only then $HTTP::SimpleLinkChecker::ERROR is set.
Unreachable hosts or unresolvable hostnames aren't among these,
they result in a 500 status code. A sensible check would thus be:
my @good_links = grep {
my $stats = check_link($_);
defined($stats) && $stats < 400;
} @links;
-Chris
------------------------------
Date: Sat, 17 May 2014 09:22:07 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: A question about grep
Message-Id: <slrnlne3gv.9rl.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-16 10:57, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>> 'Not' some string is not well documented, but seems to return an
>> empty string if the string is not empty and 1 if the string is empty.
>
> ! is documented as 'returns the logical negation of its right operand'
> and perlsyn(1) states that
>
> Truth and Falsehood
> The number 0, the strings '0' and '', the empty list "()", and
> "undef" are all false in a boolean context. All other values are
> true. Negation of a true value by "!" or "not" returns a special
> false value. When evaluated as a string it is treated as '', but
> as a number, it is treated as 0.
>
> How's that "not well documented"?
It doesn't document what negation of a false value returns. (although I
doubt that this is what Martijn meant, since it isn't specific to
strings.)
It is also in the wrong place. The return values of operators should be
documented in perlop. The special false value should probably be
documented in perldata and maybe true/false values in general, too
(although that needs to be at least mentioned/referenced in perlsyn,
too).
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 17 May 2014 04:45:05 -0700 (PDT)
From: Martin Lee <liyaoxinchifan@gmail.com>
Subject: Re: A question about grep
Message-Id: <4b10c914-2e27-4620-a425-a0637e8cbb6d@googlegroups.com>
> The last can be even be boiled down to:
>
>
>
> print "$_\n" for grep defined(check_link($_)), @links;
>
>
>
> But that is a matter of taste, when learning Perl, it's better not to be
>
> overly smart and terse.
Thank you, I agree with you, and I think your synx is cool!
------------------------------
Date: Thu, 15 May 2014 13:36:39 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <ll38gm$eq7$1@speranza.aioe.org>
On 5/12/2014 3:46 PM, Tim McDaniel wrote:
> In article <mM2dna38mqJp2ezOnZ2dnUVZ8rOdnZ2d@giganews.com>,
> Henry Law <news@lawshouse.org> wrote:
>> #!/usr/bin/perl
>> use strict;
>> use warnings;
>> use 5.010;
>>
>> sub tryit {
>> my ( $user, $conf, $parms ) = @_;
>> $@ = "reset_user: invalid parameters\n" and return if $parms==1;
>> $@ = "reset_user: '$user' doesn't exist\n" and return if $parms==2;
>> }
>
> I think you should stop dicking with the builtin $@ variable. "man
> perlvar" says what happens when a few builtin variables are assigned
> to, but $@ isn't one of them, so I see no guarantee that it will work.
>
>> If I compile it Perl warns me: "Found = in conditional, should be == at
>> tryout.pl line 8."
>
> Well, yeah. "and" takes two operands, and the first operand is
> evaluaed in a boolean context (a conditional), and
> $@ = "reset_user: invalid parameters\n"
> indeed has = in a conditional, as stated. A pirated Programming
> Perl says "the final value of the variable on the left is returned as
> the value of the assignment as a whole", so the LHS is always true, so
> it works, for some value of "works".
>
> $@ = 3+4 and return if $parms==1;
> produces the same warning.
>
>> But line 9 is virtually identical, except for the presence of an
>> interpolated variable, and it compiles clean! Blowed if I know why.
>
> At a guess, the "Found = in conditional" warning is a heuristic that
> gets confused somehow by an interpolated string in particular. That
> is, it's the lack of a message line 9 that is the problematic one, not
> line 8.
>
>> Aside from explaining what I've misunderstood, what's the most Perlish
>> way to set a variable and return, all in one statement?
>
> Is there a problem with the comma operator?
> $frog = "green", return if blort();
>
> But personally I don't like flow of control in an expression, so I'd
> just write
> if (blort()) {
> $frog = "green";
> return;
> }
>
Alternative if comma operator "ist nicht schoen bei mir".
do {$frog="green"} and return if blort();
--
Charles DeRykus
------------------------------
Date: Thu, 15 May 2014 21:29:06 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <ll3bj2$oa0$1@reader1.panix.com>
In article <ll38gm$eq7$1@speranza.aioe.org>,
Charles DeRykus <derykus@gmail.com> wrote:
>Alternative if comma operator "ist nicht schoen bei mir".
>
>do {$frog="green"} and return if blort();
I would say "and" is intrinsically fragile for this. In most cases in
Perl, where you can use a constant, you can use an expression. ("use"
is the only counterexample I thought of off the top of my head.)
But not here:
do { $frog = "green" } and return if blort();
will always work, but
do { $frog = $toad } and return if blort();
will fail if $toad happens to have one of the Perl false values.
Either use comma, or make it a standard "if" block.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 15 May 2014 15:13:19 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <ll3e62$rnq$1@speranza.aioe.org>
On 5/15/2014 2:29 PM, Tim McDaniel wrote:
> In article <ll38gm$eq7$1@speranza.aioe.org>,
> Charles DeRykus <derykus@gmail.com> wrote:
>> Alternative if comma operator "ist nicht schoen bei mir".
>>
>> do {$frog="green"} and return if blort();
>
> I would say "and" is intrinsically fragile for this. In most cases in
> Perl, where you can use a constant, you can use an expression. ("use"
> is the only counterexample I thought of off the top of my head.)
>
> But not here:
>
> do { $frog = "green" } and return if blort();
>
> will always work, but
>
> do { $frog = $toad } and return if blort();
>
> will fail if $toad happens to have one of the Perl false values.
I think I'd backstop it in non-trivial cases: do{ ... ;1}
>
> Either use comma, or make it a standard "if" block.
The comma op is ok. Not in this example, but, a d'oh moment is possible
with a comma op too: ....,return or ....
I think I'd use a "do" block if short; otherwise, "if".
--
Charles DeRykus
------------------------------
Date: Fri, 16 May 2014 13:17:57 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87mweh6hoq.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 5/15/2014 2:29 PM, Tim McDaniel wrote:
>> In article <ll38gm$eq7$1@speranza.aioe.org>,
>> Charles DeRykus <derykus@gmail.com> wrote:
>>> Alternative if comma operator "ist nicht schoen bei mir".
>>>
>>> do {$frog="green"} and return if blort();
>>
>> I would say "and" is intrinsically fragile for this. In most cases in
>> Perl, where you can use a constant, you can use an expression. ("use"
>> is the only counterexample I thought of off the top of my head.)
>>
>> But not here:
>>
>> do { $frog = "green" } and return if blort();
>>
>> will always work, but
>>
>> do { $frog = $toad } and return if blort();
>>
>> will fail if $toad happens to have one of the Perl false values.
>
> I think I'd backstop it in non-trivial cases: do{ ... ;1}
>>
>> Either use comma, or make it a standard "if" block.
>
> The comma op is ok. Not in this example, but, a d'oh moment is
> possible with a comma op too: ....,return or ....
Did you ever inherit a relatively large body of code various people of
varying competence-levels and copy'n'past-happiness worked on for some
time? 'Accidental meanings', that is, code which doesn't make any
literal sense and requires 'inside information' about the thoughts of
the author while writing it (possibly shadowed by the fact that the bit
in question is the 25th mutated copy of something which originally
appeared in a totally different context) are a HUGE understanding
impediment: Some guy who isn't you and possibly doesn't even know you
won't a priori be aware of the fact that the do in
do { $frog = 'green' } and return if blort()
is a 'clever hack' supposed to silence a compiler warning which occurred
because the compiler considered this a boolean expression instead of a
'funky' sequencing construct. This would warrant a comment documenting
it and then, things start to get really silly because that will end up
as something
# this is the wrong way but I like it
do { $frog = 'green' } and return if blort()
and it adds even more useless noise to the text.
'Stubbornly refusing to listen'-story which has to be told in this
context: Once upon a time in the past, I encountered a guy who
complained about the technical inferiority of g++ (GNU C++-compiler)
because it would usually abort with an out-of-memory-error when
"compiling moderately large functions of only a few thousand lines". The
idea that this could mean that his coding style was so far beyond
anything resembling 'rhyme and reason' that nobody could imagine that
the compiler would ever need to deal with something like that and that
'structure your code' would be a brilliant solution to this problem
apparently never occured to him.
------------------------------
Date: Fri, 16 May 2014 09:43:12 -0500
From: John Black <johnblack@nospam.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <MPG.2ddfdff74be1cb489897d0@news.eternal-september.org>
In article <87mweh6hoq.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
says...
>
> Did you ever inherit a relatively large body of code various people of
> varying competence-levels and copy'n'past-happiness worked on for some
> time? 'Accidental meanings', that is, code which doesn't make any
> literal sense and requires 'inside information' about the thoughts of
> the author while writing it (possibly shadowed by the fact that the bit
> in question is the 25th mutated copy of something which originally
> appeared in a totally different context) are a HUGE understanding
> impediment:
Words of wisdom suitable for framing...
> 'Stubbornly refusing to listen'-story which has to be told in this
> context: Once upon a time in the past, I encountered a guy who
> complained about the technical inferiority of g++ (GNU C++-compiler)
> because it would usually abort with an out-of-memory-error when
> "compiling moderately large functions of only a few thousand lines". The
> idea that this could mean that his coding style was so far beyond
> anything resembling 'rhyme and reason' that nobody could imagine that
> the compiler would ever need to deal with something like that and that
> 'structure your code' would be a brilliant solution to this problem
> apparently never occured to him.
However, g++ should not abort with an out of memory error in this case. That's a big
function but not unreasonably big (like a million lines of code).
John Black
------------------------------
Date: Fri, 16 May 2014 16:17:47 +0000 (UTC)
From: "Dave Saville" <No-Spam@deezee.org>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <fV45K0OBJxbE-pn2-uTcVd6e6vCkd@paddington.bear.den>
On Fri, 16 May 2014 12:17:57 UTC, Rainer Weikusat
<rweikusat@mobileactivedefense.com> wrote:
> Did you ever inherit a relatively large body of code various people of
> varying competence-levels and copy'n'past-happiness worked on for some
> time?
BTDTGTTS
Two more senior than I programmers I worked with. One, who taught me
BAL, started his variables at "a" - "z", then "aa" - "zz" then "aaa"
You get the idea. Brilliant mathematician though.
The other would make up what would appear to be a meaningful name in
the context of the science - but wasn't. To this day I have never
decided which was the worse to try and figure out. I think the latter
because at least with the first you knew they were not related to
anything and not go off on incorrect assumptions.
Recently been involved in an project where the original authors were
cut n paste happy. The lead programmer of today christened it "the
curse of the duplicated code" due to somone in the past finding a bug
and fixing N out of M copies. :-( N usually being *much* smaller
than M.
--
Regards
Dave Saville
------------------------------
Date: Fri, 16 May 2014 09:27:29 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <rrecn9tqbfj7uka7drur1enthgk94tso1j@4ax.com>
"Dave Saville" <No-Spam@deezee.org> wrote:
>Recently been involved in an project where the original authors were
>cut n paste happy. The lead programmer of today christened it "the
>curse of the duplicated code"
Oh come on. I am waaaaayyyyy more productive than you are, I produce 5
times the number of lines of code.
And lines of code is the only thing the bean counters and penny pinchers
know how to measure .....
jue
------------------------------
Date: Fri, 16 May 2014 22:04:36 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87zjih77vf.fsf@sable.mobileactivedefense.com>
"Dave Saville" <No-Spam@deezee.org> writes:
[...]
> Recently been involved in an project where the original authors were
> cut n paste happy. The lead programmer of today christened it "the
> curse of the duplicated code" due to somone in the past finding a bug
> and fixing N out of M copies. :-( N usually being *much* smaller
> than M.
Related problem: "The Curse of the Mutated Manifold" --- a bunch of
operations which are generally similar in nature, yet sufficiently
different that no two manifest copies of the template code are actually
identical, maybe with one or two which weren't copied from a common
ancestor but implemented independently in a completely different way
thrown in for good measure. Then, some non-trivial change has to be made
to all of them ...
It is usually possible to re-organize something like this into a class
hierarchy with the bulk of the code going into the base class and
subclasses overriding some 'generic operations' in order to provide
their individual flavouring and IMHO, that's preferable to something
like implementing (and testing and debugging) sixteen different
'identical changes' in various places of the code.
------------------------------
Date: Fri, 16 May 2014 18:25:29 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <ll6dqe$nrd$1@speranza.aioe.org>
On 5/16/2014 5:17 AM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
..
>> The comma op is ok. Not in this example, but, a d'oh moment is
>> possible with a comma op too: ....,return or ....
>
> Did you ever inherit a relatively large body of code various people of
> varying competence-levels and copy'n'past-happiness worked on for some
> time? 'Accidental meanings', that is, code which doesn't make any
> literal sense and requires 'inside information' about the thoughts of
> the author while writing it (possibly shadowed by the fact that the bit
> in question is the 25th mutated copy of something which originally
> appeared in a totally different context) are a HUGE understanding
> impediment: Some guy who isn't you and possibly doesn't even know you
> won't a priori be aware of the fact that the do in
>
> do { $frog = 'green' } and return if blort()
>
> is a 'clever hack' supposed to silence a compiler warning which occurred
> because the compiler considered this a boolean expression instead of a
> 'funky' sequencing construct. This would warrant a comment documenting
> it and then, things start to get really silly because that will end up
> as something
>
> # this is the wrong way but I like it
> do { $frog = 'green' } and return if blort()
Through an extremist's prism, most of Perl's TIMTOWDI looks like a hack.
They'll complain there's no need for "do" blocks or statement qualifiers
for that matter... yuck! Not how "real coders" operate.
To me a compiler warning doesn't equate to "wrong way". "Uninitialized
value" warnings are routinely turned off. It doesn't warrant an apology
or a comment or the slavish exclusivity of "if" blocks or comma op's as
the "One True Way".
OTOH, Larry say something like: "just because Perl gives you ten ways
to do something, doesn't mean all of them are the best way". I can
appreciate the view that even TIMTOWDI may get a bad rep if carried to
extremes.
--
Charles DeRykus
------------------------------
Date: Sat, 17 May 2014 08:05:36 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <slrnlndv1g.9rl.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-15 20:36, Charles DeRykus <derykus@gmail.com> wrote:
> On 5/12/2014 3:46 PM, Tim McDaniel wrote:
>> In article <mM2dna38mqJp2ezOnZ2dnUVZ8rOdnZ2d@giganews.com>,
>> Henry Law <news@lawshouse.org> wrote:
>>> $@ = "reset_user: invalid parameters\n" and return if $parms==1;
[...]
>>> Aside from explaining what I've misunderstood, what's the most Perlish
>>> way to set a variable and return, all in one statement?
>>
>> Is there a problem with the comma operator?
>> $frog = "green", return if blort();
>>
>> But personally I don't like flow of control in an expression, so I'd
>> just write
>> if (blort()) {
>> $frog = "green";
>> return;
>> }
>>
>
> Alternative if comma operator "ist nicht schoen bei mir".
>
> do {$frog="green"} and return if blort();
>
How about:
do { $frog="green"; return } if blort();
Avoids the problem with short-circuiting and, uses the braces to group
together what belongs together and saves two key strokes ;-).
Of course once you are there you might just use an ordinary if(){} as
Tim suggested.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 17 May 2014 02:29:41 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <ll7a68$hlj$1@speranza.aioe.org>
On 5/16/2014 11:05 PM, Peter J. Holzer wrote:
> On 2014-05-15 20:36, Charles DeRykus <derykus@gmail.com> wrote:
>> On 5/12/2014 3:46 PM, Tim McDaniel wrote:
>>> In article <mM2dna38mqJp2ezOnZ2dnUVZ8rOdnZ2d@giganews.com>,
>>> Henry Law <news@lawshouse.org> wrote:
>>>> $@ = "reset_user: invalid parameters\n" and return if $parms==1;
> [...]
>>>> Aside from explaining what I've misunderstood, what's the most Perlish
>>>> way to set a variable and return, all in one statement?
>>>
>>> Is there a problem with the comma operator?
>>> $frog = "green", return if blort();
>>>
>>> But personally I don't like flow of control in an expression, so I'd
>>> just write
>>> if (blort()) {
>>> $frog = "green";
>>> return;
>>> }
>>>
>>
>> Alternative if comma operator "ist nicht schoen bei mir".
>>
>> do {$frog="green"} and return if blort();
>>
>
> How about:
>
> do { $frog="green"; return } if blort();
>
> Avoids the problem with short-circuiting and, uses the braces to group
> together what belongs together and saves two key strokes ;-).
>
> Of course once you are there you might just use an ordinary if(){} as
> Tim suted.
>
Tim wins then :) But one of the "TIMTOWDI fringe" may still turn up and
say "Forget if{} ...I'll do it my way without an extra scope:"
blort() and $frog="green" and return;
--
Charles DeRykus
------------------------------
Date: Sat, 17 May 2014 22:24:22 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <m4tk4b-pdu.ln1@news.rtij.nl>
On Fri, 16 May 2014 09:27:29 -0700, Jürgen Exner wrote:
> "Dave Saville" <No-Spam@deezee.org> wrote:
>>Recently been involved in an project where the original authors were cut
>>n paste happy. The lead programmer of today christened it "the curse of
>>the duplicated code"
>
> Oh come on. I am waaaaayyyyy more productive than you are, I produce 5
> times the number of lines of code.
> And lines of code is the only thing the bean counters and penny pinchers
> know how to measure .....
My most productive sessions have a negative LOC count.
M4
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4214
***************************************
