On 06/24/2013 08:46 AM, lee wrote:
John Delacour <johndelac...@gmail.com> writes:
What you are saying is rather like expecting meaning from a sentence
It tells you to stop when it's raining and to open your umbrella.
like:
“Stop if it’s raining, open your umbrella.”
Nobody would know what you intend to say. No condition is actually
attached to “stop”.
last if $its_raining;
By your logic, no condition is attached to "last". The problem with
perl is that it doesn't allow you to open your umbrella.
i have been following this thread and i haven't seen a good explanation
to you about what is really going on.
first off, last and th if modifier have nothing to do with each other.
last is a just a normal builtin and the if modifier can be appended to
any statement. why you think last behaves differently with if i cannot
fathom. the important point is that last executes immediately and any
expressions after it will not be executed.
last and print "foo" ; # will never print foo.
print "foo" and last ; # will always print foo.
both of those could be appended with an if modifier. and guess what?
they behave the same as before IF the if condition gets met. otherwise
the entire statement is skipped. the if modifier is great but is best
used on short simple statements. complex statements (multiple parts with
and/or/comma, etc) are best done in an if block.
last by itself is simple and goes well with if modifier.
last if SOME_LOOP_CHECK ;
next unless OTHER_CHECK ;
those are very common and readable perl statements.
as for the ternary (or conditional) operator, it is designed for its
return value. its precedence and that of other ops works fine if it just
returns one of two expression. when you get into assignment, the
precedence blows up and you need parens. also its best idiom is to only
return a value and not do a side effect. printing is a side effect as is
last and other flow controls. sure you can do what you want in ?: but it
is poor perl if you do anything but use its value.
so you can code however you want but when people look at your code later
on they will question it and wonder why you chose the wrong idioms. this
will affect code review, job prospects, and more. there are reasons both
logical and social why some idioms are better than others. learn the
reasons and your code will be better and easier to read and maintain.
thanx,
uri
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
