Re: RFC 14 (v2) Modify open() to support FileObjects and
[email protected] (Chaim Frenkel) 05 Aug 2000 23:21:23 -0400
| Newsgroups | perl.perl6.language.io |
|---|---|
| Message-ID | <[email protected]> |
I can see a need to keep the sys* functions (and perhaps add more.) When the coding is at a high level, some simple things become impossible. Many years ago, I read through the volumes on the Apple Toolbox. I don't recall much, but I do recall what seemed to be an effort on the designers part to supply both low level and higher level capablities. If it is possible to get both the higher level and the lower level implementation layers to be active at the same time would be great. But don't lose the access to the bare metal. <chaim> >>>>> "PRL" == Perl6 RFC Librarian <[email protected]> writes: PRL> The open() functions would have to be altered to accept this new syntax PRL> and return full-fledged B<fileobjects>. The functions C<opendir()>, PRL> C<sysopen()>, C<socket()>, and possibly many others must be rewritten PRL> to serve as "shortcuts" to the new extensible C<open()>. PRL> With regards to now-obsolete functions (such as C<opendir>, C<sysopen>, PRL> C<socket>, and many more), we should make one of two choices: PRL> 1. Make them shortcuts to the long form PRL> 2. Remove them outright PRL> If we choose #2 (I think #1 might actually be the right answer), we PRL> should probably make nicknames for these modules, such as "dir" for PRL> IO:Dir, "socket" for IO::Socket, and so forth, so a person can type: PRL> $dir = open "/usr/bin", dir; # instead of IO::Dir PRL> Finally, to make the full, extensible class form useful, we will have to PRL> figure out what type of modular hooks it will have. They may look like PRL> C<tie()>, with hooks for every operation, or they may be completely PRL> different, just requiring an C<OPEN()> function in the module. If all PRL> modules agreed to return a consistent object from this C<OPEN()> call, PRL> then the file routines could potentially be highly-optimized, since PRL> there would only have to be one core set. If possible, this is what I'd PRL> like to see. -- Chaim Frenkel Nonlinear Knowledge, Inc. [email protected] +1-718-236-0183