At 02:49 PM 11/29/00 +0000, Nicholas Clark wrote:
>On Wed, Nov 29, 2000 at 09:38:44AM -0500, Dan Sugalski 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.
>
>I liked Tom Huges' suggestion of 3 or so simple wrappers (which I've
>deleted now, oops) because it let PerlIO make the choice between doing
>something simple to open the named file, and something complicated but
>fast. (and I belive Nick's p5p perlio is suggesting that PerlIO could open
>a handle that sits atop the FILE *)
>
>But on the other hand I also liked Simon Cozen's argument that it should
>be easy to embed somewhere else, in which case why do we want to make
>the parser have a dependency on the IO library?
>
>Bah. Can't have them both at the same time.
Sure we can. There's no reason the API exposed to programs that embed perl
needs to be the same as what perl exposes to other pieces of itself, or to
extensions, or to opcode functions. (Though I'd be a bit nervous if most
opcode functions were calling the parser)
The mistake I made was lumping them together too much. A dead-simple, one
function interface is good for the programmer who's going to spend all of
15 minutes on the perl embedding code, but is sub-optimal for everyone else)
Anyway, now that everyone's had a chance to chew this one over, would
someone like to propose an alternative?
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
