At 01:19 PM 12/6/2001 -0500, Melvin Smith wrote:
>Would we prefer to leave the current system call names as-is (open,close
>read,seek) as the direct call through versions and name
>the IO routines pio_open, ... or go the route of Perl and do
>sys_open, etc. for the raw system call versions and name the Parrot IO
>API as the default names (open,close)?
The intent's those opcodes are all there is for the I/O system presented to
a parrot program, and the opcode functions do the right thing depending on
things like filenames, flags passed to open, and the filters pushed on the
I/O streams.
Arguably open needs beefing, and we might need to define how filters get
pushed, popped, spliced, listed, called, and generally work (well, OK, it'd
be good if we told people what they needed to do... :) but doing:
read P1, P2
should read a line/record regardless of whether the filehandle's open on a
socket, a file, a sub-process, some sort of tied thingie, or a database,
and it shouldn't matter if there are a dozen filters all twiddling the data
between source and sink.
That was my plan, at least. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
