Re: Treating filehandles like strings

2000-08-07-20:43:29 Nathan Wiger:
> > I'd rather have a filehandle stringify to
> > the filename instead.
> 
> Great minds think alike. :-) I was actually going to add this to the new
> version of the open() RFC as a possible use of RFC 49's
> soon-to-be-renamed STRING method. 
> 
> Now I know I have at least I have one supporter! ;-)

Me too!

Long Ago and Far Away, when the world was much younger and the first
camel not yet published, I was a hard-core C programmer. I'd evolved
myself a helper library that did a great many things for me, one
major one of which I still haven't gotten with perl yet, maybe this
rewrite will make it possible.

One of the most valuable features was that the very large majority
of the helper routines I used, were simply wrappers around the
standard facilities, that didn't require any error checking: the
routine succeeded, or it printed a suitable error message and then
died. In the case of file handles, and error reporting for the calls
that manipulated them, I had a helper array that stashed a copy of
the information that was used to initialize the file handle. The
error message could then use the filename if it was known, and fall
back to a name like "stdin" or "stdout", or a phrase like "file
descriptor #n", if nothing more descriptive fit.

The one language (or is it implementation?) feature I'm going to
be pushing for the hardest, will be to guarantee that _every_
builtin that can return an error, can be wrapped, most especially
and noteably "print". Once they can all be wrapped, finishing
up Fatal.pm so it's actually convenient and useful won't be too
traumatic a project, and I'll breathe a big sigh of relief when I
can just add "use Fatal qw(:all);" to the top of all my perl scripts
and forever more ditch all the " or die ..." clauses.

So back to the topic here, arranging for the best practical
description of the origins of the filehandle, for error-message
purposes, to be made available as the stringification of the
filehandle object, would be very, very handy indeed.

-Bennett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5kFubL6KAps40sTYRAvefAJ9y6HoBIBoPz1c1Cmo4cfUxDp3pFwCeJofb
r+9rf6xKF0ePIgLgbrMNjZI=
=n/om
-----END PGP SIGNATURE-----