Nicholas Clark <[EMAIL PROTECTED]> writes:
>On Mon, Nov 27, 2000 at 05:17:47PM +0000, Nicholas Clark wrote:
>> On Mon, Nov 27, 2000 at 11:09:03AM -0500, Chaim Frenkel wrote:
>> > >>>>> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
>>
>> > Look throught the RFCs this was one of Damian Conway's.
>> >
>> > <chaim> =~ /RFC/
>>
>> http://dev.perl.org/rfc/93.html
>>
>> I know I read it, I just don't remember reading it.
>>
>> IMPLEMENTATION
>>
>> Dammit, Jim, I'm a doctor, not an magician!
>>
>> Probably needs to be integrated with IO disciplines too.
>>
>> He's right, but Nick's intending to implement an unread() (rather than just
>> ungetc()) so there should be enough rope for people to implement whatever
>> knots take their fancy (including the Jack Ketch knot)
>>
>> Hugo makes some comments about implementation of this in:
>> http:[EMAIL PROTECTED]/msg00459.html
>
>Bah. meant to add that it might be logical for
>
> <chaim> =~ /RFC/
>
>to seek to the beginning of the file before it starts
>
> <chaim> =~ /\GRFC/gc
>
>carries on from the previous position and doesn't seek back to the beginning
>(or otherwise throw all the buffered data away)
>
>Which effectively makes pos analogous to seek/tell.
I was musing on how to make "layers" visible to perl code.
And using pos() to point at the current position in the buffer
(note the _buffer_ not the _file) was one idea I came up with.
>So do we get rid of poss and seek() our scalars? :-)
Keep pos() and loose seek ;-)
>It also allows the possibility of pos on file handles being fsetpos/fgetpos
>Maybe that should have been an rfc 3 months ago, and really doesn't even
>matter if perlio obsoletes stdio and internalises stdio's distinction between
>text and binary streams.
>
>BTW I am serious about needing a /gc not to chuck the buffered data.
>
>It makes something like
>
> @found = <chaim> =~ /RFC +(\d+)/;
>
>not spend time stacking a lot of data back that's only about to be discarded.
>
>But this isn't internals really, is it? I'm miles off topic.
>
>Nicholas Clark
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
