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