develooper Front page | perl.perl5.porters | Postings from June 2008

Re: [perl #56150] return return

Thread Previous | Thread Next
Aristotle Pagaltzis
June 23, 2008 13:18
Re: [perl #56150] return return
Message ID:
* Mark Mielke <> [2008-06-23 19:55]:
> I don't trust Perl, and (unfortunately) our code needs to run
> on Perl 5.004 and before.

How about finding out instead of dumbing the code down to your
level of insecurity? :-)

> If somebody can convince me that all versions of Perl 5.004 and
> later will ALWAYS treat 'foo' as literal without quotes in this
> context, I'll be happy to drop it. It may have been Perl
> earlier than 5.004 that sometimes did unexpected things with:
>    $foo{time} = 2;

Are you sure you don’t have that backwards? Because I know that
many people get surprised by the *opposite* case, where they
expected the function to be called but it gets interpreted
literally as a string instead – eg. here:

    use constant BAZ => 'bar;
    $foo{BAZ} = 'quux';

They expect to find `quux` under the key `bar`, but instead Perl
uses `BAZ` as the literal key.

In any case hash key auto-quoting has never done anything
unexpected for me. As long as the key is a valid bareword, it
gets quoted. The rule is very simple and consistent, and I avoid
keys that won’t fit the rule as much as possible so I can avoid
the quotes whenever possible.

> Better to consistently use quotes everywhere.
> Such is my opinion and style. Is it comparable to return vs
> not? It's similar but not the same. In the case of consistent
> quoting, it means I can use all values without worrying about
> it failing for me one day. In the case of return, both work
> fine and will not fail one day.

It’s not comparable to `return` vs nothing, but it’s comparable
to `WHATEVER if ($cond)` vs `WHATEVER if $cond`, which is an
example you brought up.

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About