Groups | Search | Server Info | Login | Register
Groups > comp.lang.perl.misc > #4772
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Newsgroups | comp.lang.perl.misc |
| Subject | Re: $var = do { ... }? |
| Date | 2012-03-16 17:46 +0000 |
| Message-ID | <87mx7gh21q.fsf@sapphire.mobileactivedefense.com> (permalink) |
| References | <jiqv7d$6k4$1@reader1.panix.com> <jjt7p5$e3g$1@reader1.panix.com> <4f633b3d$0$6845$e4fe514c@news2.news.xs4all.nl> |
"Dr.Ruud" <rvtol+usenet@xs4all.nl> writes:
> On 2012-03-15 18:09, Tim McDaniel wrote:
>
>> So I have to make sure the code evaluates the desired return value as
>> the last thing in the block, like
>>
>> my $result = do {
>> if ($i % 2 == 0) { 'even' }
>> elsif ($i % 3 == 0) { 'divisible by 3' }
>> elsif ($i % 5 == 0) { 'divisible by 5' }
>> else { 'just wrong' }
>> };
>>
>> Is there a clever way in Perl 5 to metaphorically return early with a
>> value?
>
> That if/elsif/else of yours already does that. Remember that
> perl-the-binary compiles to opcodes. So the 'elsif' is only done if
> the 'if' didn't do.
"When the program compiles, the machine is happy" (R. Pike). But since
code is not write-only, there should be other considerations beyond
'making the machine happy'. The way and if - else construct works is
that it provides, based on some set of conditions, a set of
alternative codepaths to follow at some point of an otherwise linear
movement, ie, after one of the alternate code paths was chosen,
execution is supposed to continue with the next statement after the
if. People tend to use it even if no such next statement exists, at
least partially cause by a misunderstanding of some statement about
'structure programming', namely, that 'a module' (subroutine) should
have a single entry and exit point. This essentially doesn't make any
sense[*] in language designed with this dictum in mind because
subroutines always have a single entry point and they always have a
single exit point (that's the location where execution of the calling
code continues after the subroutine finished(!)). Later, this
statement has been re-interpreted to mean that the control-flow inside
a subroutine should be contorted to give the illusion as if all
possible codepaths through the subroutine would 'naturally' end after
the last statement in the corresponding block. And that's IMO not a
good idea.
Back to comp.lang.perl.misc | Previous | Next — Previous in thread | Find similar
$var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-02 17:15 +0000
Re: $var = do { ... }? merlyn@stonehenge.com (Randal L. Schwartz) - 2012-03-02 09:52 -0800
Re: $var = do { ... }? Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2012-03-02 13:42 -0500
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-02 18:44 +0000
Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-02 19:00 +0000
Re: $var = do { ... }? merlyn@stonehenge.com (Randal L. Schwartz) - 2012-03-02 11:45 -0800
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-02 20:06 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 19:18 +0000
Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-02 19:24 +0000
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-02 20:10 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 20:43 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 22:47 +0000
Re: $var = do { ... }? Martijn Lievaart <m@rtij.nl.invlalid> - 2012-03-03 15:58 +0100
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-03 17:11 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-03 17:19 +0000
Re: $var = do { ... }? Martijn Lievaart <m@rtij.nl.invlalid> - 2012-03-03 23:58 +0100
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-04 00:29 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-04 14:44 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-05 20:50 +0000
Re: $var = do { ... }? "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2012-03-05 11:35 +0100
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-05 15:22 +0000
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-05 16:38 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-02 20:44 +0000
Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-15 17:09 +0000
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-16 00:18 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 14:25 +0000
Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-16 21:01 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 21:37 +0000
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-16 22:56 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 23:54 +0000
Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-17 18:48 +0000
Re: $var = do { ... }? Ben Morrow <ben@morrow.me.uk> - 2012-03-17 22:53 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-18 15:40 +0000
Re: $var = do { ... }? "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2012-03-16 14:08 +0100
Re: $var = do { ... }? tmcd@panix.com (Tim McDaniel) - 2012-03-16 15:25 +0000
Re: $var = do { ... }? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-03-16 17:46 +0000
csiph-web