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
