On Mar 11, 2006, at 2:07, Nicholas Clark wrote:
I feel more comfortable with the idea of IO being methods on PMCs
than raw
OPs.
They are methods on I/O objects internally. (Just as most opcodes on
PMCs actually call vtable methods.) So, the question isn't as
significant as it appears. It's really just "Do we provide a simple
opcode interface for the most common operations on I/O objects?"
Which is an easy "yes".
However, I think that the biggest thing is seeing how the Perl 5 IO
works,
where all the IO ops have to redispatch if the "file handle" turns
out to be
tied, and in turn the PerlIO system has a whole second level of
redispatch
at the C level of "overloading the file handle's behaviour". Oh,
and then
there's PerlIO::via which hooks that C level back up to Perl methods.
That's a Perl 5 problem that Parrot handles with vtables. It's not
specific to I/O.
So a single level of method calls feels much cleaner, as that means
only 1
level of dispatch, however the program is re-implementing IO, be it
writes
to tied scalars, character set conversion, or merely a direct IO
with the
most native operating system interfaces.
It's not quite that simple, as you still have the I/O layers.
Allison
