Tom Hughes <[EMAIL PROTECTED]> writes:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> At 10:42 AM 11/29/00 +0000, Nick Ing-Simmons wrote:
>>
>> >FILE * is not a good idea. PerlIO * is fine.
>>
>> The problem with that is we're potentially getting the filehandle from
>> something that isn't perl. Or so my thinking went at the time. Right
>> now I'm thinkng that I need to rethink things.
That was my point. The Parser API should stick to PerlIO * - which is
an abstract interface. How that interface gets provided is none
of the _parser's_ business.
There is another side to this - perl itself (particularly on Win32 or
other places where stdio is "broken") may not have a FILE * to give
you - it may only have PerlIO *.
>
>That shouldn't matter so long as there's a simple way to create
>a PerlIO * from a FILE * or whatever.
Bleadperl work on PerlIO is teaching that it is not necessarily "simple" to
convert one to the other. One can wrap a FILE * inside a PerlIO simply
enough, provided that the provider then promisses not to touch it in
anyway while perl is messing with it, but the FILE *-ness gets
exposed. For example there are issues with FILE *'s
'textmode' and PerlIO's crlf layer fighting. Unless we inherit perl5's
twin-IO * concept (which I would not recommend at this stage) there are also
issues with bi-directional things like sockets.
It is (currently) much better to open a PerlIO * from the outset,
either from a pathname, or a low level "file descriptor" (what a
low-level descriptor is on non-UNIX is work in progress).
Now we should be able to clean that up some (even in perl5) but
we don't want to expose all the mess to the _parser_ API.
If we say FILE * we _may_ have to say - FILE *, open in binmode, not
line buffered, not to a socket on Win32, ... and a whole host
of other gunk. And then (presumably) inside the parser wrapper do
the right thing to turn it into a PerlIO * so we can use UTF8,
CRLF, encode/decode etc.
Better (IMHO) to do that _outside_ the parser API under another
committee's juristiction.
>
>That's probably something that needs to be specific to different
>language bindings - if you're embedding perl in C++ you probably
>have an iostream, and if you're embedding in Java you'll have a
>Java stream object. In each case you'll want an easy way to create
>a PerlIO object from that.
Why not export the PerlIO API and have language call that?
But if not possible then we can write
parse_FILE(FILE *x,...)
which takes the FILE *, wraps in in a PerlIO * calls the generic Parser
unwraps can cleans up and returns.
>
>Tom
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
