On Wed, Jul 27, 2005 at 07:09:41AM -0700, Randal L. Schwartz wrote:
: With the recent realization of the beginnings of a PIL->Javascript
: emitter, it appears that my Perl6 program can run in a bizarre mix of
: execution environments.
:
: Forgive me if I missed this while trying to skim through the unearthly
: number of perl6 messages so far, but...
:
: It'd be nice if there was one central object that represented "the
: execution platform", with various methods based on the capabilities.
Yes, we'll have something like that, but...
: For example, this object, call it $*OS, could be queried to see
: if we can get a native Javascript class (true only when running on
: a JSplatform):
:
: if $*OS.can("get_javascript_class") { # I'm running on a js platform
: my $main_window = $*OS.get_javascript_class("Window").main;
: ...
: }
:
: The point would be to have one object that would "understand" the
: platform dependent parts, and have a consistent naming for the methods
: that are used by that object as the execution platform varies.
It's not entirely clear that "get_javascript_class" should be considered
a method of the OS and/or platform for which .can would be appropriate.
The method might be supplied by the platform, or it might be supplied
merely because someone somewhere said "use JS" and imported the behavior.
So in this particular case it might be better to just say
if exists &get_javascript_class {...}
or maybe (if it's actually the time to get the class) just try
calling the routine and catch the exception, unless you're trying
to second-guess ahead of time. Or ask the language loader object
whether it has loaded JS. I'm just saying that the language loader
doesn't necessarily have to be considered part of the OS.
But that aside, yes, we'll have visiblility into $?OS (the compile-time
OS) and $*OS (the run-time OS). Or maybe those are just the names,
and hashes like %?OS<feature> and %*OS<feature> are the appropriate forms
for interrogating particular items. But $*OS as an object can subsume
both of those behaviors and also provide methods, so that's probably
the right way to go.
On the other hand, it's also not entirely clear that all platformish
feature sets should make themselves visible through one name. What's
an "OS"? Should we distinguish "VM" from that? Should we be able
to peer through VM and OS and get at MACHINE? What if it's running on
multiple machines and they want to give conflicting advice?
Arguably, it's probably good to have a single access point for
everything outside the VM, and OS is as good a name as anything for
that, as the abstraction of "the world". (Hmm, if your program is
"the flesh", that leaves the VM to be "the devil", I guess.) However,
if we do that, then it would have to be recognized that the entire
Internet is hiding inside that OS bubble.
So I guess the question is whether we need $?VM and $*VM as well? Or
should we consider the VM to also be "foreign" and lump it with OS?
: This is similar to the OS-9's "gestalt" tables, which got smarter as
: the operating system had more features, but was a consistent way to
: ask "do we have a color monitor here?".
:
: Is something like this already planned?
Yes, but we just need to be careful not to recreate The Registry.
We're looking more for "a place for everything and everything in
its place", but we're still trying to understand what that means.
As you say, whatever we end up with does have to be extensible,
since we don't know all the "places" we'll want ten years from now.
It seems to me that the more places we can come up with now, though,
the less likely we are to have collisions later, unless our categories
are artificial. That tends to argue for separating out VM from OS,
and maybe COMPUTER, and NET, unless you think that NET =:= COMPUTER.
Larry
