On 6 February 2013 19:35, Ted Zlatanov <t...@lifelogs.com> wrote:
> On Wed, 6 Feb 2013 19:25:43 +0100 demerphq <demer...@gmail.com> wrote:
>
> d> On 6 February 2013 19:05, Ted Zlatanov <t...@lifelogs.com> wrote:
>>> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gits...@pobox.com> wrote:
>>>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>>>
>>> Oh yes! Not that I recommend it, and I'm not even going to touch on
>>> Perl Golf :)
>
> d> I think you are wrong. Can you provide an example?
>
> d> Larry specifically wanted to avoid the "dangling else" problem that C
> d> suffers from, and made it so that blocks are mandatory. The only
> d> exception is statement modifiers, which are not only allowed to omit
> d> the braces but also the parens on the condition.
>
> Oh, perhaps I didn't state it correctly. You can avoid braces, but not
> if you want to use if/elsif/else/unless/etc. which require them:
>
> condition && do_this();
> condition || do_this();
> condition ? do_this() : do_that();
>
> (and others I can't recall right now)
>
> But my point was only that it's always possible to get around these
> artificial restrictions; it's more important to ask for legible sensible
> code. Sorry if that was unclear!
Ah ok. Right, at a low level:
if (condition) { do_this() }
is identical to
condition && do_this();
IOW, Perl allows logical operators to act as control flow statements.
I hope your document include something that says that using logical
operators as control flow statements should be used sparingly, and
generally should be restricted to low precedence operators and should
never involve more than one operator.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
