=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
