develooper Front page | perl.perl5.porters | Postings from February 2013

Re: perlopentut modernization

Thread Previous | Thread Next
February 14, 2013 10:54
Re: perlopentut modernization
Message ID:
On 14 February 2013 09:55, Alexander Hartmaier <> wrote:
> On Thu, Feb 14, 2013 at 6:29 AM, demerphq <> wrote:
>> Personally what I would like to see Alexander do to improve this patch
>> is to fix the examples like this:
>> open(my $fh, "<", $filename) || die "can't open $filename: $!";
>> so they look like this:
>> open my $fh, "<", $filename
>>    or die "Can't open '$filename' for read: $!";
>> IOW, so they use the low precedence "or" and not the high precedence
>> || (which dictates the use of parens on the open), and then eliminate
>> the parens on the open statement, quote the filename in the error
>> message, and show the open mode in the error message.
> I changed all occurrences of or in the doc to be the same and also talked to
> people on #p5p which of the two I should use. As far as I remember the
> outcome was to use the low-precedence form for exactly this reason.
> Furthermore I did change all examples to have the or die on a second,
> indented line. I only left the first section of examples untouched, those
> where changed by Dave so now all are like that. Which branch/commit did you
> review?

I read the patch in this thread. Maybe i missed a more up to date version?

>> In practice I almost _never_ see parens on an open statement. And if
>> parens are going to be used they should be used on BOTH the open and
>> the die so that the form is consistent. But I would really prefer that
>> the standard idiom be used and see the pares omitted from both.
> This is also something I've asked on #p5p and the agreement was to include
> parens to prevent possible parser edge cases.

IMO whoever said that was spreading FUD. Almost nobody in real code
uses the parens.

> This matches my personal preference of using parens even if not absolutely
> needed to increase readability and avoid precedence errors.

IMO there is no point in modernizing the doc if it doesnt track modern
practice, and IME modern practice is to not put the parens on.

The only reason I know to put parens on is to allow people to use high
precedence operators as control flow, which IMO is a bad idea as it
requires people to use the parens. Only using low precedence operators
means it doesnt need to use the parens, but you can... (Yes I realize
this is slightly circular logic, such is life.)

IMO it would not be such a bad thing if back in the day high
precedence operators produced warnings when used as control flow.

>> Making sure the errors message shows the mode, and quotes the filename
>> is IMO invaluable for tracking down issues (unquoted filenames become
>> problematic when for instance the filename being opened is called "\n"
>> or "" or " " or whatnot), and knowing if you failed to write or read a
>> file can make a big difference to debugging.
> I'm agreeing with you, I do both in all my code. I didn't change it because
> I guessed not everybody likes it and that the current form of error messages
> was the way it is for a reason.

I think it would be better to fix this. All too often I have had to
fix scripts to add this information in and then let the error I was
trying to debug happen again so I could figure out what file was being
touched and why.


perl -Mre=debug -e "/just|another|perl|hacker/"

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