Summary of I/O related RFCs

=head1 Summary of I/O related RFCs

Please correct my misunderstandings and omitions.  This (or something
like it) should be sent up to perl6-language.

=over

=item 2  (v1): Request For New Pragma: Implicit (language)

Values in void context would be printed to the default filehandle.

  use implicit;
  "Print me!\n";

Chaim Frenkel <[email protected]> objected that this could lead to
maintenance nightmares.  Larry Wall <[email protected]> said that it would
be ok "as long as it's lexically scoped, and doesn't rely on a global
default filehandle."

=item 10 (v3): Filehandles should use C<*> as a type prefix if typeglobs
are eliminated.  (retracted)

Much discussion resulted in the conclusion that: "A filehandle is a
singular whatzitz.  It thus mandatory takes the singular prefix; to wit,
$." -- Tom Christiansen <[email protected]> 

=item 14 (v2): Modify open() to support FileObjects and Extensibility 

open() would be overhauled to be even more powerful(!) and return a
fileobject.  This a complex proposal and should be required reading for
anyone interested in the future of I/O in perl.  One of the more
interesting aspects is the idea that open() can be extended to open any
type of I/O object: files, directories, ftp, http, sockets, etc.  The
key is to hand the work to a module that speaks the language.

Nick Ing-Simmons <[email protected]> pointed out that the class that
handles I/O (IO::File, IO::Dir, etc.) should be hidden from the user. 
Instead open should try to figure out that out internally.  There was
some discusion that open could could accept URLs and choose a I/O class
based on the scheme.  See <http://www.w3.org/Addressing/>.  I look
forward to v3.

=item 30 (v1): STDIN, STDOUT, and STDERR should be renamed (language)

They should become $STDIN, $STDOUT, and $STDERR.  John Porter
<[email protected]> facetiously suggested $TDIN, $TDOUT, and $TDERR. 
There was no other discussion.

=item 33 (v1): Eliminate bareword filehandles. (language)

No discussion.

=item 34 (v1): Angle brackets should not be used for file globbing. 

Some discussion that resulted in the consensus Perl 6 should not start
out with any "deprecated" features.

=item 36 (v1): Structured Internal Representation of Filenames
(internal)

No discussion of the proposal that "Wherever Perl internally uses
filenames (in a very inclusive sense: filenames, directory names,
whatever) the components of the file name should be stored in a
platform-neutral structured format."  It also included: "A vague
possibility: the proposed internal format could be designed to be
flexible enough to present also URLs/URIs."

=item 39 (v1): print operator 

No discussion of a proposal to spell "print(LIST)" as ">LIST<".

=item 47 (v1): Universal Asynchronous I/O (language-flow)

I didn't follow the discussion as I'm not subscribed to the flow
sublist.  Most of the RFC is about the Asynchronous part, not the I/O
part.

=item 51 (v2): Angle brackets should accept filenames and lists 

A proposal to let the input operator automagicly open a list of
filehandles when it is passed a list of filenames.  This would let us
write:

  print <'/path/to/file', '/path/to', 'piped input |'>;

Chaim Frenkel pointed out that:

        $foo = <"filename">;    # 1
        $bar = <"another">;
        $gaz = <"filename">;    # 2

is ambigous.  Should $gaz be set to the first or second line of
"filename"?  I  suggested the second line, so that the while loop would
work.  Chaim responded that this could lead to some messy action at a
distance problems with multiple modules opening the same file.  I still
need to think about this.

Chaim also expressed concern that overloading < and > would create
confusion for perl and programmers.  I said that they would simply
replace the file-globbing mode found in perl 5.

=item 52 (v1): List context return from filesystem functions (language)

From the ABSTRACT:

C<chmod>, C<chown>, and C<unlink> return the I<number> of successfully 
affected files.  I suggest that in a list context, they return the
I<names> 
of the I<unsuccessfully> affected files.  Add C<rmdir> to that list as 
well, since although it currently only takes one directory name as
input, 
there is no reason it shouldn't take a list.

Although this is counterintuitive, it makes error reporting from these
functions much easier.

=back

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King