[32186] in Perl-Users-Digest
Perl-Users Digest, Issue: 3451 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 22 18:09:22 2011
Date: Fri, 22 Jul 2011 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 Fri, 22 Jul 2011 Volume: 11 Number: 3451
Today's topics:
Re: syntax query: ($var++ && next) if /match/ <justin.1104@purestblue.com>
Re: syntax query: ($var++ && next) if /match/ <justin.1104@purestblue.com>
Re: syntax query: ($var++ && next) if /match/ <justin.1104@purestblue.com>
Re: syntax query: ($var++ && next) if /match/ <rweikusat@mssgmbh.com>
Re: syntax query: ($var++ && next) if /match/ <jurgenex@hotmail.com>
Re: syntax query: ($var++ && next) if /match/ <rweikusat@mssgmbh.com>
Re: syntax query: ($var++ && next) if /match/ sln@netherlands.com
Re: syntax query: ($var++ && next) if /match/ sln@netherlands.com
Re: syntax query: ($var++ && next) if /match/ <jurgenex@hotmail.com>
Re: syntax query: ($var++ && next) if /match/ <rweikusat@mssgmbh.com>
Re: syntax query: ($var++ && next) if /match/ sln@netherlands.com
Re: syntax query: ($var++ && next) if /match/ <mvdwege@mail.com>
Re: syntax query: ($var++ && next) if /match/ sln@netherlands.com
Re: syntax query: ($var++ && next) if /match/ <rweikusat@mssgmbh.com>
Re: syntax query: ($var++ && next) if /match/ <kst-u@mib.org>
Re: syntax query: ($var++ && next) if /match/ sln@netherlands.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 22 Jul 2011 12:48:16 +0100
From: Justin C <justin.1104@purestblue.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <0l4of8-1et.ln1@zem.masonsmusic.co.uk>
On 2011-07-21, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>> Willem <willem@toad.stack.nl> writes:
>>>> Rainer Weikusat wrote:
>
> [...]
>
>>>> ) (($seen = 1) && next) if /^paul/;
>
> [...]
>
>>>> ($seen = 1 and next) if /^paul/;
>>>
>>> Arguably a better idea. But the parenthesises can be dropped as well,
>>> making this
>>>
>>> $seen = 1 and next if /^paul/;
>>>
>>> which I consider to be preferable.
>>
>> Some might consider
>>
>> if (/^paul/) {
>> $seen = 1;
>> next;
>> }
>>
>> to be preferable.
>
> Or
>
> /^paul/ and $seen = 1, next;
>
> You can put in on several lines if you're afraid your enter key might
> feel lonely otherwise
>
> /^paul/
> and
> $seen
> =
> 1
> ,
> next
> ;
C'mon guys, now you're getting silly. I was going for a balance between
brevity and legibility. Using a block does not have much brevity, but
has a lot of legibility - it was what my original code had (I was
younger and less experienced then). OTOH $seen = 1 and next if... is
brief to the detriment of legibility (or understandability), at least
for me. So far I have decided that ($seen = 1 and next) if ... is the
best solution for me... let's see what else this thread shows up before
I commit myself!
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 22 Jul 2011 13:18:19 +0100
From: Justin C <justin.1104@purestblue.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <bd6of8-lfu.ln1@zem.masonsmusic.co.uk>
On 2011-07-22, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
> Justin C wrote:
>>
>> I have:
>>
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>>
>> my $seen = 0;
>> my @arr = qw/john paul george ringo/;
>>
>> for (@arr) {
>> ($seen = 1 && next) if /^paul/;
>> next unless $seen;
>> print $_, "\n";
>> }
>>
>> __END__
>>
>> which prints no output. But if I change the `&&` to a comma it does as
>> expected.... ($seen = 1, next) if ...
>>
>> I've just read perldoc perlop for Comma Operator, and for&&, but I
>> don't understand why one works and the other doesn't. Can anyone explain
>> this in simple terms?
>
> If your intention is to perform two operations,
> relying on the quirk that your first operation
> evaluates to "true" is quite dirty.
I understand what you mean by 'relying on the quirk that [my] first
operation evaluates to true...' (I've been accused of that before, but
I'm open to education as to why I shouldn't be doing these things, and I
try to not repeat bad practice). But I'm not sure I am doing as you
suggest, if I am would you please explain it differently as I'm not
seeing it as explained. I am not trying to assign the result of 'next'
to $seen (as someone posted was happening in one of the versions of the
line, in another post).
My intention is to set a variable $seen to 1 (true) (for use later), to
stop processing the current item and move on to the next if $_ matches
certain criteria.
The code from which the above is a reduction, is used to read input from
a file with man lines and a certain format. Until a line matching a
particular string is reached all is discarded. Once a particular line is
reached then a switch is thrown ($seen = 1) and the following lines are
processed by my program. Once a further line is reached I call 'last' as
I don't wish to even look at the rest of the file.
> (I'm deliberately ignoring the operator binding issue,
> and addressing intent, here).
>
> If $seen were $absent, with inverted logic, you'd need
> to change the operator from && to || which is just horrible.
>
> Perl has perfectly good syntax for "bundling" operations;
> abusing (or attempting to abuse) a conditional operator
> is not a good idea.
Yeah, I'm definitely lost now. I don't mean to be a PITA, but I don't
yet speak perl well enough - I understand some of the terminology, but
not enough to understand you here.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 22 Jul 2011 13:18:27 +0100
From: Justin C <justin.1104@purestblue.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <jd6of8-lfu.ln1@zem.masonsmusic.co.uk>
On 2011-07-21, Willem <willem@toad.stack.nl> wrote:
> Rainer Weikusat wrote:
>) The precedence of && is higher than that of =, meaning,
>)
>) $seen = 1 && next is equivalent to $seen = (1 && next) or (as
>) B::Deparse would tell you) $seen = next. And next doesn't return a
>) value, hence, $seen is never set. The obvious way to fix this:
>
> ...
>) for (@arr) {
>) (($seen = 1) && next) if /^paul/;
>
> Or you use 'and':
>
> for (@arr) {
> ($seen = 1 and next) if /^paul/;
[snip]
Ah, I see from perlop:
"...when used for control flow, Perl provides 'and' and 'or' operators.
The short-circuit behavious is identical."
Thanks, Willem. It appears that when I read there are somethings that
just don't get past the retina.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 22 Jul 2011 16:09:17 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <87sjpy9wte.fsf@sapphire.mobileactivedefense.com>
Justin C <justin.1104@purestblue.com> writes:
> On 2011-07-21, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>> Willem <willem@toad.stack.nl> writes:
>>>>> Rainer Weikusat wrote:
>>
>> [...]
>>
>>>>> ) (($seen = 1) && next) if /^paul/;
>>
>> [...]
>>
>>>>> ($seen = 1 and next) if /^paul/;
>>>>
>>>> Arguably a better idea. But the parenthesises can be dropped as well,
>>>> making this
>>>>
>>>> $seen = 1 and next if /^paul/;
>>>>
>>>> which I consider to be preferable.
>>>
>>> Some might consider
>>>
>>> if (/^paul/) {
>>> $seen = 1;
>>> next;
>>> }
>>>
>>> to be preferable.
>>
>> Or
>>
>> /^paul/ and $seen = 1, next;
>>
>> You can put in on several lines if you're afraid your enter key might
>> feel lonely otherwise
>>
>> /^paul/
>> and
>> $seen
>> =
>> 1
>> ,
>> next
>> ;
>
> C'mon guys, now you're getting silly. I was going for a balance between
> brevity and legibility. Using a block does not have much brevity, but
> has a lot of legibility -
A text doesn't become easier to understand by adding more
non-alphanumeric characters to it.
> it was what my original code had (I was
> younger and less experienced then). OTOH $seen = 1 and next if... is
> brief to the detriment of legibility (or understandability),
Why this, since it does exactly what its literal meaning appears to
be:
$seen = 1 and next if /^paul/
(set $seen to 1 and execute next if $_ matches /^paul/)
------------------------------
Date: Fri, 22 Jul 2011 08:49:12 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <ap6j27hdop7pda1msgkme0ftis6n72pbsi@4ax.com>
Justin C <justin.1104@purestblue.com> wrote:
>My intention is to set a variable $seen to 1 (true) (for use later), to
>stop processing the current item and move on to the next if $_ matches
>certain criteria.
What's wrong with an old-fashioned
if ($_ matches certain criteria) {
$seen = 1;
next;
}
Just because Perl has conditional statements doesn't mean that you have
to squeeze everything into that mold.
jue
------------------------------
Date: Fri, 22 Jul 2011 17:04:05 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <87hb6e5mkq.fsf@sapphire.mobileactivedefense.com>
Jürgen Exner <jurgenex@hotmail.com> writes:
> Justin C <justin.1104@purestblue.com> wrote:
>>My intention is to set a variable $seen to 1 (true) (for use later), to
>>stop processing the current item and move on to the next if $_ matches
>>certain criteria.
>
> What's wrong with an old-fashioned
> if ($_ matches certain criteria) {
> $seen = 1;
> next;
> }
The signal-to-noise ratio of this encoding of this particular operation
is worse than that of the equivalent statement-modifier or logical
operating using variants. Additionally, it is less efficient although
this could be regarded as a deficiency of the perl compiler. The only
'positive' thing about it is that it looks more familiar to people who
are versed in 'other curly-bracket languages'.
------------------------------
Date: Fri, 22 Jul 2011 09:36:07 -0700
From: sln@netherlands.com
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <n48j27hmga29ebvdu5jo0po3mbslhs7s54@4ax.com>
On Fri, 22 Jul 2011 13:18:19 +0100, Justin C <justin.1104@purestblue.com> wrote:
>On 2011-07-22, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>> Justin C wrote:
>>>
[...]
>>> which prints no output. But if I change the `&&` to a comma it does as
>>> expected.... ($seen = 1, next) if ...
>>>
>>> I've just read perldoc perlop for Comma Operator, and for&&, but I
>>> don't understand why one works and the other doesn't. Can anyone explain
>>> this in simple terms?
>>
>> If your intention is to perform two operations,
>> relying on the quirk that your first operation
>> evaluates to "true" is quite dirty.
>
>I understand what you mean by 'relying on the quirk that [my] first
>operation evaluates to true...' (I've been accused of that before, but
>I'm open to education as to why I shouldn't be doing these things, and I
>try to not repeat bad practice). But I'm not sure I am doing as you
>suggest,
[...]
Performing asignment as part of a conditional expression,
even variable modification, is not really a safe bet if you
want the remainder of the expression to be evaluated.
Furthermore, it lacks clarity and is hard to maintain,
even for the person who wrote it.
I think Perl tries to compensate its formal conditional
requirement of wrapping code in a block braces, spcifically
even 1 line, that for example C/C++ doesen't, with an offering
of code before conditional; ie: $seen=1 if (condition)
The more formal conditional structure of
if (condition){
code;
}
is preferred to me.
>
>> (I'm deliberately ignoring the operator binding issue,
>> and addressing intent, here).
>>
>> If $seen were $absent, with inverted logic, you'd need
>> to change the operator from && to || which is just horrible.
>>
>> Perl has perfectly good syntax for "bundling" operations;
>> abusing (or attempting to abuse) a conditional operator
>> is not a good idea.
>
>Yeah, I'm definitely lost now. I don't mean to be a PITA, but I don't
>yet speak perl well enough - I understand some of the terminology, but
>not enough to understand you here.
>
>
That could just as well have been said about C/C++.
-sln
------------------------------
Date: Fri, 22 Jul 2011 09:55:03 -0700
From: sln@netherlands.com
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <sq9j275bj692rrg52cp38321u2fagam729@4ax.com>
On Fri, 22 Jul 2011 17:04:05 +0100, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>Jürgen Exner <jurgenex@hotmail.com> writes:
>> Justin C <justin.1104@purestblue.com> wrote:
>>>My intention is to set a variable $seen to 1 (true) (for use later), to
>>>stop processing the current item and move on to the next if $_ matches
>>>certain criteria.
>>
>> What's wrong with an old-fashioned
>> if ($_ matches certain criteria) {
>> $seen = 1;
>> next;
>> }
>
>The signal-to-noise ratio of this encoding of this particular operation
>is worse than that of the equivalent statement-modifier or logical
>operating using variants. Additionally, it is less efficient although
>this could be regarded as a deficiency of the perl compiler. The only
>'positive' thing about it is that it looks more familiar to people who
>are versed in 'other curly-bracket languages'.
I would disagree with this.
1. Efficiency is relative and insignificant
unless its your only line of code.
2. Like it or not, Perl is a curly-bracket language.
Try writing a program without them.
Since it is, the probability is that its hard to
maintain:
(code) if (condition);, or
code if condition;
3. The greatest benefit is reaped from clarity
of intent. If you want to focus on performance,
design it in with external lib calls, or
don't use Perl, use assembly or C.
Some constructs I like in RPN.
unless() is one of them when the code body
is not a conditional.
-sln
------------------------------
Date: Fri, 22 Jul 2011 10:00:02 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <u69j2714c9b2lgjdgje21k2972slkghnbq@4ax.com>
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>Jürgen Exner <jurgenex@hotmail.com> writes:
>> Justin C <justin.1104@purestblue.com> wrote:
>>>My intention is to set a variable $seen to 1 (true) (for use later), to
>>>stop processing the current item and move on to the next if $_ matches
>>>certain criteria.
>>
>> What's wrong with an old-fashioned
>> if ($_ matches certain criteria) {
>> $seen = 1;
>> next;
>> }
>
>The signal-to-noise ratio of this encoding of this particular operation
>is worse than that of the equivalent statement-modifier or logical
>operating using variants. Additionally, it is less efficient although
>this could be regarded as a deficiency of the perl compiler. The only
>'positive' thing about it is that it looks more familiar to people who
>are versed in 'other curly-bracket languages'.
I disagree. This isn't one operation, it is two and they are quite
different. One assignment and one loop control jump. And therefore it
should look and feel like two operations, i.e. be separated into two
statements.
You can easily see how confusing it is to munge them together: in just
this very thread there are already at least three different
interpretions of what the OP intended the code to do.
It is just not worth this confusion. Consice code that is easy to
understand is way more important than shorting the code to the max.
Unless you are playing Perl golf, of course.
Also, I am not convinced about your efficieny argument. For one nobody
asked for the code to be as efficient as possible. And even if so I
would still find it hard to believe that an if statement is slower,
because in both cases the same operations are performed. Or actually in
case of the statement modifier there is even an additional and.
Not to mention that such micro-optimizations are rarely the right
approach. If a program is too slow then almost always a different
algorithm or a different overall approach is the answer. If you are
really depending upon such micro-optimizations then probably you should
have chosen a different programming language, probably one that allows
lower-level control like C or assembler.
jue
------------------------------
Date: Fri, 22 Jul 2011 18:04:54 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <87vcuu456x.fsf@sapphire.mobileactivedefense.com>
sln@netherlands.com writes:
> On Fri, 22 Jul 2011 13:18:19 +0100, Justin C <justin.1104@purestblue.com> wrote:
>>On 2011-07-22, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>>> Justin C wrote:
>>>>
> [...]
>
>>>> which prints no output. But if I change the `&&` to a comma it does as
>>>> expected.... ($seen = 1, next) if ...
>>>>
>>>> I've just read perldoc perlop for Comma Operator, and for&&, but I
>>>> don't understand why one works and the other doesn't. Can anyone explain
>>>> this in simple terms?
>>>
>>> If your intention is to perform two operations,
>>> relying on the quirk that your first operation
>>> evaluates to "true" is quite dirty.
>>
>>I understand what you mean by 'relying on the quirk that [my] first
>>operation evaluates to true...' (I've been accused of that before, but
>>I'm open to education as to why I shouldn't be doing these things, and I
>>try to not repeat bad practice). But I'm not sure I am doing as you
>>suggest,
> [...]
>
> Performing asignment as part of a conditional expression,
> even variable modification, is not really a safe bet if you
> want the remainder of the expression to be evaluated.
Provided the assigment returns the required value it is perfectly
safe.
> Furthermore, it lacks clarity and is hard to maintain,
> even for the person who wrote it.
Could you perhaps explain why you think that 'it lacks clarity and is
hard to maintain' (instead of just asserting that it does)?
> I think Perl tries to compensate its formal conditional
> requirement of wrapping code in a block braces, spcifically
> even 1 line, that for example C/C++ doesen't, with an offering
> of code before conditional; ie: $seen=1 if (condition)
This is probably supposed to prevent the so-called 'dangling else
problem' in C or C++ where some people apparently manage to fool
themselves into believing that identation could change semantics,
namely, that
if (a)
if (b) ...;
else ...;
would mean if (a) { if (b) ...; } else ... instead of
if (a) { if (b) ...; else ...; }. But as opposed to C or C++, blocks
are not 'free' at runtime in perl, although at least the 5.10.1
compiler can meanwhile optimize a single-statement conditional block
away and statement modifiers use to be documented as having the
advantage of 'being able to avoid the overhead of entering a block.
Independently of this, they make the text easier to read[*] for short,
conditionally executed sequences.
[*] This assumes that 'reading' happens left to right from top
to bottom of a text, *not* by indentation-based 'recursive
descent parsing'.
------------------------------
Date: Fri, 22 Jul 2011 10:32:25 -0700
From: sln@netherlands.com
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <0gcj27hksgeadpbgiuf6aumo7f1991ljt5@4ax.com>
On Fri, 22 Jul 2011 12:48:16 +0100, Justin C <justin.1104@purestblue.com> wrote:
>So far I have decided that ($seen = 1 and next) if ... is the
>best solution for me... let's see what else this thread shows up before
>I commit myself!
>
Whats wrong with doing something like this:
next if /^paul/ and $seen = 1;
-sln
------------------------------
Date: Fri, 22 Jul 2011 19:33:41 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <86zkk6jk3u.fsf@gareth.avalon.lan>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Jürgen Exner <jurgenex@hotmail.com> writes:
>> Justin C <justin.1104@purestblue.com> wrote:
>>>My intention is to set a variable $seen to 1 (true) (for use later), to
>>>stop processing the current item and move on to the next if $_ matches
>>>certain criteria.
>>
>> What's wrong with an old-fashioned
>> if ($_ matches certain criteria) {
>> $seen = 1;
>> next;
>> }
>
> The signal-to-noise ratio of this encoding of this particular operation
> is worse than that of the equivalent statement-modifier or logical
> operating using variants.
It's a bloody 'if' block, not COBOL, for crying out loud.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Fri, 22 Jul 2011 11:11:33 -0700
From: sln@netherlands.com
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <67ej279pbhucoe1g3do7dlumfvnhmrcrq9@4ax.com>
On Fri, 22 Jul 2011 18:04:54 +0100, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>sln@netherlands.com writes:
>> On Fri, 22 Jul 2011 13:18:19 +0100, Justin C <justin.1104@purestblue.com> wrote:
>>>On 2011-07-22, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>>>> Justin C wrote:
>>>>>
>> [...]
>>
>>>>> which prints no output. But if I change the `&&` to a comma it does as
>>>>> expected.... ($seen = 1, next) if ...
>>>>>
>>>>> I've just read perldoc perlop for Comma Operator, and for&&, but I
>>>>> don't understand why one works and the other doesn't. Can anyone explain
>>>>> this in simple terms?
>>>>
>>>> If your intention is to perform two operations,
>>>> relying on the quirk that your first operation
>>>> evaluates to "true" is quite dirty.
>>>
>>>I understand what you mean by 'relying on the quirk that [my] first
>>>operation evaluates to true...' (I've been accused of that before, but
>>>I'm open to education as to why I shouldn't be doing these things, and I
>>>try to not repeat bad practice). But I'm not sure I am doing as you
>>>suggest,
>> [...]
>>
>> Performing asignment as part of a conditional expression,
>> even variable modification, is not really a safe bet if you
>> want the remainder of the expression to be evaluated.
>
>Provided the assigment returns the required value it is perfectly
>safe.
>
>> Furthermore, it lacks clarity and is hard to maintain,
>> even for the person who wrote it.
>
>Could you perhaps explain why you think that 'it lacks clarity and is
>hard to maintain' (instead of just asserting that it does)?
>
>> I think Perl tries to compensate its formal conditional
>> requirement of wrapping code in a block braces, spcifically
>> even 1 line, that for example C/C++ doesen't, with an offering
>> of code before conditional; ie: $seen=1 if (condition)
>
>This is probably supposed to prevent the so-called 'dangling else
>problem' in C or C++ where some people apparently manage to fool
>themselves into believing that identation could change semantics,
>namely, that
>
> if (a)
> if (b) ...;
> else ...;
>
>would mean if (a) { if (b) ...; } else ... instead of
>if (a) { if (b) ...; else ...; }. But as opposed to C or C++, blocks
>are not 'free' at runtime in perl, although at least the 5.10.1
>compiler can meanwhile optimize a single-statement conditional block
>away and statement modifiers use to be documented as having the
>advantage of 'being able to avoid the overhead of entering a block.
>
>Independently of this, they make the text easier to read[*] for short,
>conditionally executed sequences.
>
> [*] This assumes that 'reading' happens left to right from top
> to bottom of a text, *not* by indentation-based 'recursive
> descent parsing'.
Well, I guess Perl saved us C/C++ programmers from that
dangling else, now they offer the code block before the
conditional to compensate. Nice move.
I don't know that enterring a code block is overhead.
Traditionally, its more like skipping the block with a jump,
instead of passing through. But, who knows what Perl does.
If its that bad in condition blocks, sub calls must be a dog.
I think most compilers can optimize code blocks at compile time.
Traditionally, its a different issue if the block has runtime elements.
-sln
------------------------------
Date: Fri, 22 Jul 2011 19:46:00 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <87pql240if.fsf@sapphire.mobileactivedefense.com>
sln@netherlands.com writes:
> On Fri, 22 Jul 2011 12:48:16 +0100, Justin C <justin.1104@purestblue.com> wrote:
>
>>So far I have decided that ($seen = 1 and next) if ... is the
>>best solution for me... let's see what else this thread shows up before
>>I commit myself!
>>
>
> Whats wrong with doing something like this:
>
> next if /^paul/ and $seen = 1;
It suggests that the $seen = 1 is actually part of the condition
which, in turn, will very likely make someone wonder whether or not it
was really supposed to be $seen == 1. While the '$seen = 1 and next if'
reads very 'naturally' (assuming the reader is familiar with English)
it is sort-of an abuse.
------------------------------
Date: Fri, 22 Jul 2011 11:55:34 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <ln62mujgbd.fsf@nuthaus.mib.org>
Justin C <justin.1104@purestblue.com> writes:
> On 2011-07-21, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>> Willem <willem@toad.stack.nl> writes:
>>>>> Rainer Weikusat wrote:
>>
>> [...]
>>
>>>>> ) (($seen = 1) && next) if /^paul/;
>>
>> [...]
>>
>>>>> ($seen = 1 and next) if /^paul/;
>>>>
>>>> Arguably a better idea. But the parenthesises can be dropped as well,
>>>> making this
>>>>
>>>> $seen = 1 and next if /^paul/;
>>>>
>>>> which I consider to be preferable.
>>>
>>> Some might consider
>>>
>>> if (/^paul/) {
>>> $seen = 1;
>>> next;
>>> }
>>>
>>> to be preferable.
>>
>> Or
>>
>> /^paul/ and $seen = 1, next;
>>
>> You can put in on several lines if you're afraid your enter key might
>> feel lonely otherwise
>>
>> /^paul/
>> and
>> $seen
>> =
>> 1
>> ,
>> next
>> ;
>
> C'mon guys, now you're getting silly. I was going for a balance between
> brevity and legibility. Using a block does not have much brevity, but
> has a lot of legibility - it was what my original code had (I was
> younger and less experienced then). OTOH $seen = 1 and next if... is
> brief to the detriment of legibility (or understandability), at least
> for me. So far I have decided that ($seen = 1 and next) if ... is the
> best solution for me... let's see what else this thread shows up before
> I commit myself!
Personally, I consider legibility to be *much* more important than
brevity.
I dislike the "$seen = 1 and ..." solutions partly because the
"and" is used only for sequencing; it's depends on the left operand
being true. If you tried to use the same thing elsewhere, but with
"$seen = 0" instead, you'd have to restructure the code.
I consider
if (/^paul/) {
$seen = 1;
next;
}
to be *much* better than your suggested
($seen = 1 and next) if /^paul/;
If the condition (/^paul/) is true, you want to do two things: set $seen
to 1 and "next". That kind of thing is what if statements are for.
Of course TMTOWTDI, but some Ways To Do It are kinder to readers and
future maintainers than others.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Fri, 22 Jul 2011 15:04:51 -0700
From: sln@netherlands.com
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <56rj27hltair8dfcvkf56jlnvv8sgp2tm9@4ax.com>
On Fri, 22 Jul 2011 19:46:00 +0100, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>sln@netherlands.com writes:
>> On Fri, 22 Jul 2011 12:48:16 +0100, Justin C <justin.1104@purestblue.com> wrote:
>>
>>>So far I have decided that ($seen = 1 and next) if ... is the
>>>best solution for me... let's see what else this thread shows up before
>>>I commit myself!
>>>
>>
>> Whats wrong with doing something like this:
>>
>> next if /^paul/ and $seen = 1;
>
>It suggests that the $seen = 1 is actually part of the condition
>which, in turn, will very likely make someone wonder whether or not it
>was really supposed to be $seen == 1. While the '$seen = 1 and next if'
>reads very 'naturally' (assuming the reader is familiar with English)
>it is sort-of an abuse.
Thats true, it does read better but doesen't emit a (asignment) warning.
That can probably be turned off though.
I still prefer a block in this case.
-sln
------------------------------
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 3451
***************************************
