tilly made some good points on his recent answer to a problem.

That makes me think of something that crossed my mind once before here.

As a matter of style, going forward, shall we forget wired HANDLE types and just use auto-vivifying locals? 

open FOO, "whatever"  or die;

[download]
becomes 
my $foo;
open $foo, "whatever"  or die;

[download]
Assuming we're not using a fancy filehandle package or anything.

—John

Replies are listed 'Best First'.
Re: auto-vivifying file handles
by demerphq (Chancellor) on Sep 25, 2001 at 15:31 UTC
    Personally It depends on the situation. If the project is so large that I need to worry about filehandles conflicting or if I in general need to pass my filehandles around then I use autovivification.

    On the other hand I recently discovered the one argument open and have started using it most of my new small scripts, mostly because it neatly packages up the variable, filehandle and die message error 

    our $FILE="/test/file.txt";
open FILE or die "$FILE: $!";

    [download]
    I can think of couple reasosn why the purist might object, but I like it, at least for ~100 line scripts. :-)

    Yves
    --
    You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

[reply]
[d/l]
Re: auto-vivifying file handles
by merlyn (Sage) on Sep 25, 2001 at 18:27 UTC
    Remember that doing such locks your code into Perl 5.6 and later, because this feature didn't exist in Perl 5.5.3. Be sure to put "require 5.6" at the top of your script. Some of us are still running 5.5.3 in production.

    -- Randal L. Schwartz, Perl hacker

[reply]
Re (tilly) 1: auto-vivifying file handles
by tilly (Archbishop) on Sep 25, 2001 at 19:31 UTC
    Well hopefully we will have error messages that also includes the filename and the contents of $!. (Like perlstyle says to do.)

    But lexically scoped filehandles have something to say for them. And you can even do it in Perl 5.005. Consider: 

    use Carp;
# time passes

# Takes a name to open, returns an open filehandle
sub my_open {
  my $file = shift;
  # Put the declaration in the open to confuse people? :-)
  my $fh = do {local *FH};
  open($fh, $file) or confess("Cannot open '$file': $!");
  return $fh;
}

    [download]
    There you are. Now you can just write: 
      my $handle = my_open("whatever");

    [download]
    and you will have lexically scoped filehandles. The only gotcha is that people may get confused about why they cannot use them like this: 
      print $self->{handle} @stuff;

    [download]
    but instead must either put the handle in a scalar, turn print into a method call, or use the syntactic trick: 
      print { $self->{handle} } @stuff;

    [download]
[reply]
[d/l]
[select]
      my $fh = do {local *FH};

      [download]
      Isn't there some perl lore surrounding this idiom? I seem to remember someone writing a 500 line module to localize a filehandle, only to have the perl community stumble upon this construct a few weeks later?

      -Blake

[reply]
[d/l]
        Well once upon a time there was a flamewar on p5p. It was not a small flamewar. It was one of those things which went on and on and on through hundreds of messages. It was originally about whether chmod should accept symbolic modes (eg "o+w" to add write permission for the owner). Some liked the idea. Others though it was bloat. Some thought that people who couldn't sling bits were better off serving Real Programmers their fries. You know how it is.

        As these things will go, it digressed. One of many threads got into some complaining about what beasts the FileHandle and IO::* modules had turned into, with a comment that the actual need was simple.

        At that point Tom Christiansen replied pointing out that the original need was already met. There was some discussion and surprise as people wondered how it worked. Not all of which is easy to trace in the link because the thread was so long that the automatic thread reconstruction is a little flaky...

        The construct was around before that. I don't know when it was originally discovered, but certainly many big names in the Perl community were surprised by it in 1999.

[reply]
      Using scalars for file handles without relying on auto-vivication: gotcha.

      What does $self->{handle} have to do with my $handle ?

      —John

[reply]
        Sorry for being unclear. My warning is that when you start using any old scalars as filehandles, people are likely to expect that you can use any construct that gives a scalar as a filehandle. Unfortunately this doesn't work.

        And a classic case that causes confusion comes when you put the handle in an object and then wonder why the obvious syntax doesn't work very well...

[reply]
Re: auto-vivifying file handles
by spudzeppelin (Pilgrim) on Sep 25, 2001 at 19:41 UTC

    This makes me wonder about whether or not we should have a cousin of the strict pragma ("marshalled"?) that would cause a compile-time error if a filehandle was used outside of the scope in which the open statement that created it would ordinarily live if it were a my, and a warning emitted if a potential conflict was detected in filehandle namespace (e.g. "Filehandle ZZZ declared at line 52, also declared at line 47 of module Barr::Baz imported by use statement at line 12.").

    And THIS also makes me wonder about whether we need to impose stricter standards (a la CPANTS) regarding filehandle naming and localization conventions within CPAN modules. In other words, that module authors should be using the method John described to insure proper scoping of filehandles.

    Spud Zeppelin * spud@spudzeppelin.com

[reply]
[d/l]
[select]

Back to Meditations