At 03:39 PM 12/6/2001 -0500, [EMAIL PROTECTED] wrote:
>So for example, open in an int context does a raw open,
>open in a scalar or PMC context does a fancy open (buffered
>or whatever) and returns a IO object?
Nope. Open always takes a string. We don't get fancy otherwise, though we
may have ways other than the open opcode to get a file PMC.
>Also, if you want the interface to be the same for all
>these ops, how do you want callbacks implemented?
>1) Are we doing callbacks?
Yup.
>2) If so, I assume they are PMC/subroutines or however you guys
> call that (I'm still unclear on where we use PMCs).
They'll be subs.
>We can either define things like callbacks and filters now
>by starting an RFC if there isn't one already, or we can
>put those things on the back burner and at last start with
>a skeleton that at least does all of the synchronous stuff, etc.
>I can start an RFC draft if you like.
I'd like to put them off for the moment and get the core bits working so we
can open plain files. We can go from there later.
>More questions...(don't you love newbies!)
Yep. Mmmmm, newbie. Bit of lemon and some flaky breading, deep fried.
Delicious!
>Is there a goal to be completely stdio independant
YES! C's stdio is the sorriest excuse for an I/O library I've ever come
across, and I've had to deal with assembly languages that did I/O with IN
and OUT opcodes. I don't think it's possible for me to say enough bad about it.
There's also the issue of efficiency--if we want I/O as fast as we can
manage, we're going to have to go a level below stdio. Makes sense--it's
not like Fortran or COBOL do their I/O via C's library, so we ought not if
we can manage.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
