http://www.perlmonks.org?node_id=1003633


in reply to Re^6: Split output by tabs
in thread Split output by tabs

The ambiguity comes between printing to a filehandle and printing a variable to STDOUT. i.e.:

That ambiguity is not solved by a "Best Practice", since it persists; the so-called "Best Practice" obscures knowledge and doesn't catch all type of errors.

$f = "foo"; # (1) # ... # time passes... (2) # ... print {$f} bar; # (3)

Here, the poor practice is, in the first place, using a meaningless single letter as a variable identifier. Second, to allow for actions at a distance using that variable. Third, not checking for the success of print which a) goes to a symbolic bareword filehandle reference (bad!) and b) most likely to a closed file handle.

These are the real problems here, and not the use or omission of curlies around every file handle expression.

And, again: it is better to know about ambiguities and how to handle them, instead of adhering to a "Best Practice" in a futile attempt to avoid them.

Think language.

Replies are listed 'Best First'.
Re^8: Split output by tabs (bogus best practice)
by ColonelPanic (Friar) on Nov 13, 2012 at 15:36 UTC

    The single-letter variable was for the purposes of the example. The example still holds with a more descriptive name--is $results_file a filehandle or a string containing the name of a file?

    More knowledge about the ambiguities of Perl is always a good thing. I don't see this practice as a replacement for knowing how things work. It just adds clarity. Braces are a nice visual cue that make a filehandle variable instantly recognizable as a filehandle.



    When's the last time you used duct tape on a duct? --Larry Wall
      Braces are a nice visual cue that make a filehandle variable instantly recognizable as a filehandle.

      Guessed that I could whip up an example where it isn't?

      qwurx [shmem] ~ > perl -le '$h = {foo => "42"}; print {$h} "foo"' Not a GLOB reference at -e line 1. qwurx [shmem] ~ >

      Aha.

      sort {byid} @list; map {$_->()} @stuff; print {$fh||$ofh} @vars;

      Braces are no nice visual cue! They mean and do something. Using them uncalled for is either decorative or cargo cult programming.

      Note that I'm not averse to the odd drink which is style, I just don't call "best practice" any blurf which doesn't hold water.

        You showed an example of how the use of braces forces Perl to try to interpret something as a file handle and to complain that $h is not a file handle (just not as clearly as it might).

        That looks like evidence in support of the claimed "best practice".

        - tye