On Tue, Jan 09, 2007 at 10:28:22PM -0800, Allison Randal wrote: : If both sync and async ops returned status objects, it would be : conveniently consistent. It would also be annoyingly heavyweight for a : simple synchronous operation, but then the biggest cost for I/O ops is : generally the I/O.
Possible optimization: for those success values that are sufficiently "uninteresting" maybe they could just be refs to constant shared objects so you avoid allocating them every time. Even if you have to return some integer like a number of characters read, this is usually the same number till the last block of the file, so that could be factored out. Or it could return a scalar plus an optional object that's only there if the scalar indicates an unthrown exception or other objectified return. Or it could be an out-of-band thing like errno, but it would just happen to be an out-of-band object instead of an integer. I can imagine various states in between where it looks out-of-band but really comes through the return interface for cleanness. And, actually, now that I think of it, the way Perl 6 handles $! is that it's always a lexical, and the fail in the called routine looks it up in the caller's lexical pad and sets it there, which foists the work off on the fail code rather than cluttering the return code. It's also cleaner than P5's global $! approach. In fact, in P6 $! is just a lexically scoped alias to the failure object that's coming back in-band anyway as an interesting undef object. We're only keeping $! for the convenience of the caller, so the caller can compose error messages as in P5. Anyway, just thought I'd toss out a few ideas. How it appears to do it, and how it actually does it may or may not be two different things depending on how much abstraction you want in your OO assembly language. And thankfully that is not my decision. :) Larry
