On Sat, 2005-03-26 at 12:48 -0800, Larry Wall wrote:
> On Sat, Mar 26, 2005 at 09:59:10AM -0500, Aaron Sherman wrote:
> Well, there is a process object, but it actually exists inside the
> operating system. It's a little silly to force people to name their
> own process all the time. I think we can assume that global variables
> belong to the current process, sort of on the "you're soaking in it"
> principle.
That seems to be a self-limiting position. It leads (as it did in Perl
5) to a desire to reduce the number of times you add access to new OS
features (as it requires global namespace suckage, though not as bad as
in Perl 5), and you'll still split out an object, module or data
structure to contain all of the information that's not in Perl proper
because it's platform specific (e.g. current drive letter context under
DOS).
I agree that $*PID is a useful alias for $*PROC.pid (though the extra *
still bothers me), but providing a unified API for interacting with
myself as an OS-level construct seems to make sense.
That's perhaps just my preference. I'm a hybrid OO/procedural guy, so I
tend to reach into the OO toolbox whenever I think it will make my life
easier.
> : If you think of the OS-level shell around a Perl interpreter as an
> : object[...]
> We can certainly have various objects proxying for various contexts.
> It's not clear how those should be broken out though. To me, an OS
> isn't a process, and there's not necessarily going to be a one-to-one
> correspondence.
True enough, and you would certainly NOT:
my $sock = $*PROC.socket;
That makes no sense at all. However, things like "what IO layer am I
using" or "am I a thread" are perfectly valid questions to pose of a
process abstraction.
> : If we consider $*PROC to be the invocant of the implicit "main", then:
> :
> : say "I am number {.pid}, who is number 1?";
> That's an interesting idea, the more so now that we're leaning away
> from .foo ever assuming the current topic unless it also happens to
> be the invocant. But it probably wouldn't do to have one common name for
> the .pid outside of methods and force people to use a different name
> inside methods. Here's where $*PID works much better, because it can
> be the same everywhere.
Well, it's always:
$*PROC.pid
The invocant goodness is just handy in a certain circumstance (what *is*
main's invocant, out of curiosity? I guess it could be the interpreter
context, but that should probably have some relationship to your process
info anyway (either is or does ... probably does.) If I were writing
Learning Perl 6, I would teach "$*PID" and/or "$*PROC.pid", but not
".pid".
