Consider the following snippets and what warnings (if any) they generate.

First, assume the following template for each of the subsequent three open calls.

use strict; use warnings; use autodie; my $filename = 'ourfile.txt'; # open call goes here.

Now consider each of the following 'open' statements to exist on its own within the preceding template:

open my $fh, '<', $filename; # No warning; open my $fh, $filename or die $! # No warning; open my $fh, $filename; # Issues a warning.

The warning issued is:

Parentheses missing around "my" list at mytest.pl line 11 (#1)

use diagnostics; adds the following output:

(W parenthesis) You said something like my $foo, $bar = @_; when you meant my ($foo, $bar) = @_; Remember that "my", "our", "local" and "state" bind tighter than c +omma.

I appreciate that the warning is trying to protect me from a situation where declaring multiple 'my' variables without parens around them would result in behavior that might not be expected. I guess what I'm pondering is the inconsistent behavior in what conditions trigger the warning. One could simply turn it off. Or one could just say open my($fh), $filename, or use the three arg open (as we should). But then what would we have to obsess over? ;)

It's fairly obvious that with the "open my $fh, '>', $filename call, that '>' string literal is not a variable, so the coder's intent is clearly to only declare a single lexical. So that situation could be ignored when talking about consistent behavior. Let's just focus on the two situations where the open is called in its two-arg form: open my $fh, $filename or die $! and open my $fh, $filename. I guess what I would be looking for (in keeping with the principle of least astonishment) would be for the syntax that generates the warning to be ignored in the context of an open statement. This already happens when an "or die $!" is appended.

I can't explain why the warning behaves as I would want it to when 'or die' is appended, and not when it's left out. Maybe someone could shed some light on that. Regardless, it seems that Perl should either complain in both situations, or in neither.

There are other examples of this behavior, such as readdir; another case where an embeded 'my' within the argument list for the built-in ought to fail to trigger a warning on missing parens. Or if it should trigger the warning, should do so always (ie, even when 'or die' is appended).


Dave


In reply to Inconsistency in warning for parens with my. by davido

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.