=head1 TITLE
Modify open() and opendir() to return filehandle objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Version: 1.0
Mailing-List: perl6-language
=head1 ABSTRACT
Currently, open() and opendir() are given handle arguments, whose values
are twiddled if a filehandle can be created:
open(HANDLE, "<$filename");
open my $fh, "<$filename";
opendir DIR, $dirname;
In order to make these functions more consistent with other
constructor-like functions (i.e. new(), etc), they should be changed to
instead return the handle objects:
$fh = open "<$filename" or die;
$dh = opendir $dirname or die;
This would make these functions more internally consistent within Perl.
=head1 DESCRIPTION
First, this RFC assumes that filehandles will be $ (single-whatzit)
types, which seems to have reached an overall informal consensus.
As many have observed, the current filehandle mechanism is insufficient
and largely "a historial accident". The goal of the redesign of file
objects is to make them as flexible and powerful as other objects within
Perl. Since we are redesigning filehandles to be true fileobjects, we
should revise their "constructor" functions as well, returning file
objects instead of twiddling values on success.
As shown above, this would change the open() function to:
$fh = open "<$filename" or die;
If successful, open() and opendir() will return file and dir objects
(respectively). On failure, they will return undef. This still allows
the user the ability to test the return value of open() and opendir() by
checking for a "true" (handle) or "false" (undef) condition.
We get a couple benefits from this approach. First, these functions
could be further extended to accept or return additional arguments. For
example, we might decide that open() can return extra "interesting
stuff" in an array context.
($fh, @other_stuff) = open $filename;
Or, we might decide that open() should be able to bind classes similar
to tie(). This could give us easy access to methods that opened HTTPD,
FTP, SSH, or other connections:
$fh = open $filename, Class::Module;
If the "Class::Module" is not specified, then "IO::Handle" (or some
other suitable alternative) could be assumed. I know this looks alot
like tie(). I'm not claiming it's a great idea, it's just an idea of how
a more general open() could give us some key benefits.
Finally, if no file arg is specified to open(), opendir(), close(), or
closedir(), I would like to propose these should assume $_, to make them
that much more consistent within Perl. This would allow one to write
loops as such:
for (@filenames) {
my $obj = open;
push @open_handles, $obj;
}
# ... stuff happens ...
for (@open_handles) {
close;
}
Perhaps this specific example is ugly (and useless), but there are
probably many more situations in which one could take advantage of this.
=head1 IMPLEMENTATION
The open() and opendir() functions would have to be altered to take one
argument (not two) and return the corresponding file object or undef.
The close() and closedir() functions would remain unchanged, acting on
the file objects:
close $fh;
closedir $dh;
Unless the parts about assuming $_ and binding classes are accepted, in
which case these will have to be added.
