> 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