>This and other RFCs are available on the web at
>  http://dev.perl.org/rfc/

>=head1 TITLE

>Eliminate bareword filehandles.

"Eliminate" is such a strong word.  You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore?  Heck, some people
still use stdin and stdout! :-)

>=head1 ABSTRACT

>Now that scalars (objects) can be used for filehandles, the bareword form
>should be eliminated.

If true, doesn't that argument hold true for functions, too?  If
all non-method functions were stored in only in variables, I guarantee
you that it would be rather harder to call a non-method function
as though it were a method.

>=head1 DESCRIPTION

>The venerable bareword form of the filehandle leads to code that is
>unnecessarily abstruse given that they can now be stored in
>scalars.  Bareword filehandles are not lexical, and require the use of
>typeglobs and C<local> to pass them to subroutines, concepts unnecessarily
>advanced for such a beginner-type operation.

It does?  

    sub p { 
        my $fh = shift;
        print $fh "got it\n";
    }
    p(STDOUT);

Of course, that's a bit dicey because STDOUT is omniglobal.   You 
could pass it as 

    p(*FH);

instead, and the function's definition doesn't change.  What I tell
people is that if they want, they can just pretend, even though
it's not quite true, that * is the type symbol for a filehandle
at least when it comes to passing it or storing in somewhere.
This works out quite well.

Of course, with prototypes, even this is unneeded:

    sub p(*) { 
        my $fh = shift;
        print $fh "got it\n";
    }
    p(FH);

Filehandles really aren't that spooky anymore.  

    sub getfh {
        return open(my $fh, "+< /dev/null") && $fh;
    } 

A simple unsubscripted scalar can virtually always be used to hold
a potentially package-qualified subroutine name, filehandle name,
a directory handle name, or a format handle name, and that scalar
used in lieu of those names (if unqualified, they're usually
package-relative, of course).  These are called "indirect function calls"
or "indirect filehandles", etc.  You can even do it with a method name, to
invoke an indirected method call (well, if you use the arrow syntax).

Indirections seem kind of nice.

--tom

Reply via email to