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

Re: [perl #56150] return return

Thread Previous | Thread Next
Mark Mielke
June 23, 2008 13:35
Re: [perl #56150] return return
Message ID:
Aristotle Pagaltzis wrote:
> * 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? :-)

I can't "find out" every year. TomC wrote a thing about it many years 
ago the last time I checked and it WAS broken in an earlier version of 
Perl 5, although Perl 5.004 seems unafflicted. I've watched people 
submit patches against exactly this $hash{key} and key => on this very 
porting list. Now, my information may be 10 years out of date - that's 
possible. But, we still use Perl 5.004, and that's at least 10 years out 
of date probably as well? :-)

But you are correct - if it's now safe, for CERTAIN, I will happily 
consider removing it from my own style guide that I provide to others. :-)

>> 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';

Yes I'm sure. Different versions of Perl have done different things. 
It's possible that everything in the last decade works. My history goes 
with Perl goes back to around 1992 and conclusions have possibly changed.

>> 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.

It's close - but where () has absolutely no impact on the statement in 
the "if" case, the quotes do have effect. The example of 
$hash{'my-variable'} vs $hash{my-variable}. Compare this to 'blah if 
condition' vs 'blah if (condition)'. In the former case it's the 
difference between working and not. In the latter case, both work fine.

If you can find a valid expression 'blah' or 'condition' where 'blah if 
condition' fails where 'blah if (condition)' succeeds, I will happily 
concede that they are the same and you are correct. Waiting for you to 
prove me wrong with held breath. :-)


Mark Mielke <>

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