> I think I'd prefer that ->pid return 0 only to the child of a fork,
> but undef on a handle that were not the product of a fork, irrespective
> of direction.

Great analysis. I think this sounds like an excellent idea.
 
> Some related issues:
> 
>     1) Did Larry or did he not mention something about dealing with
>        indirect object more cleanly?

Maybe clarify this just a little. I don't think I was present for this
discussion.

>     2) What if any reasonable use could be put to a list context
>        return from open(), or from ->pid()?

This one's still in pre-pre-pre-alpha, but I could forsee stuff like
"type"-specific data, depending on the class. For an HTTP object, maybe
the HTTP Status, Content-Type, Content-Length? I.e., stuff that would be
in objects for those that don't want objects.

Or maybe something else. I like the possibilities but I haven't
attempted to firm anything up.
 
>     3) Isn't it about time to start saving the string argument to open?
>             $fh = open("< /etc/motd");
>             print $fh->filename;
>             print $fh->mode;
>             print $fh->fileno;

Yes, yes, and yes!
 
>     4) This may become interesting for fdopens and dups.
> 
>             $fh = open("<=STDIN");
>             $fh = open("<&=STDIN");

Yeah, this is going to need a little thought...see my next email...

>         or more clearly
> 
>             $fh2 = $fh1->dup;

Yeah! That's cool.

-Nate

Reply via email to