Disclaimer: This reply comes from a badly configured client at work. Hence
the ugly format.
Sounds correct. There is already a seperate layer as you said, the "buf"
layer which should
keep track of correct semantics for seeking, etc. Also, IO should work the
same whether the
buffered layer is in the stack or not.
-Melvin
Jos Visser <[EMAIL PROTECTED]>
07/28/2003 10:38 AM
To: Juergen Boemmels <[EMAIL PROTECTED]>
cc: Perl6 Internals <[EMAIL PROTECTED]>
Subject: Re: [RfC] Semantics of clone for PIO-objects.
On Mon, Jul 28, 2003 at 03:30:46PM +0200 it came to pass that Juergen
Boemmels wrote:
> Comments
My first hunch is to see the ParrotIO object as a channel of data into
an underlying file (leaving "channel", "data", and "file" vaguely
defined for now)... This would mean that every ParrotIO object has its
own file pointer, but all copies show the exact same view of the file
(this would imply splitting the ParrotIO layer and performing buffering
in the lower/shared layer).
Then, cloning a ParrotIO object would mean creating a new ParrotIO
object that points to the same file (through the same lower/shared
representation of the file), and starts out with the same file location.
If we then write the file through P0, the data goes to the file
(buffered if necessary), but moves the logical file pointer of P0 only!
Writing to P1 would then overwrite the data just written by P1. If you
don't want that, you could call some methods to set the file pointer of
P0 to the same value as that of P1.o
Closing a ParrotIO object would close that channel into the data only.
When the last reference (reference counting! Yipiie!) to the underlying
file is closed, the lower/shared layer representation of the file would
be closed.
My 2 cents...
++Jos.es
--
ek is so lug jy vlieg deur my
sonder jou is ek sonder patroon
"Breyten Breytenbach"
