Nicholas Clark <[EMAIL PROTECTED]> writes:
>> >One way I could see of doing (some) that was to supply a discipline
>> >which took a buffer, emptied it and deleted itself. That way a departing
>> >discipline donates its input buffer, swaps in one of these, and frees
>> >itself. The new discipline simply outputs this "input" buffer until it
>> >empties, and then deletes itself.
>>
>> This may not be an unreasonable way to work _always_.
>
>In that the return value of popping a discipline is the data it sucked in
>but hadn't yet passed on. Which may be zero bytes long.
It is late and I will respond again tomorrow but I think
we need the table of functions to include:
read - give me N bytes (with a magic "as much as is to hand" value)
unread - take these bytes back
seek - move to X (from start, here, end as usual)
flush -
on write side it is simpler 'cos I have not thought about it as much
write
seek
flush - wait for drain etc.
eof - that's all folks
(and maybe "purge" = "forget what I told you we are in trouble").
I am thinking that each layer has "list of SV *" as its "buffer"
in simple cases we have a list of 0 or 1 SV *.
When we unread a hunk it gets prepended to the list.
So when we delete a "layer" it unreads any data it may have to its parent.
>
>> If a "buffer" _is_ a perl scalar then "poping" could "return" the buffer
>> which could be passed to its replacement.
>>
>> How do we pass args to discipines ?:
>>
>> binmode($fh,":+decrypt",'myPassWord');
>>
>> binmode($fh,":+drain", binmode($fh,":-$old")); # ???
>>
>> (binmode and parsing strings is begining to irk me as the way we do this
>> I find my self hankering for all the array ops
>>
>> push($fh,[\&drain,pop($fh)]);
>>
>> splice($fh,2,3,\&unzip,\&uft8)
>
>Because they map more naturally onto what we're doing.
>push,pop,shift,unshift.
>splice means you can play in the middle of the "stack"
>
>Nicholas Clark
--
Nick Ing-Simmons
