Please don't reply to this one or threadlists will be screwed up! Reply
to the second (auto-generated) one later in the perl6-language mailbox.
(Hit the button a second before Nat's email! Oh, well...)
Nathan Wiger wrote:
>
> =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.
