On Wed, Apr 29, 2009 at 5:30 AM, David-Sarah Hopwood <[email protected]> wrote: > David Foley wrote: >> Please forgive me if I'm polluting the list, and re-direct me if I am, >> but considering that there has been so much focus on browser >> implementation, that JavaScript is also employable in various >> 'environments' (IDE's, Servers etc.) and that all of these environments >> avail different features to developers, that a universal / standard >> feature detection API, perhaps through a standardised global Environment >> object, would be prudent. >> >> Are there any plans to do such? > > There will probably be some kind of module system in ES-Harmony > (which will be prototyped before then). It would make sense for that > to support querying whether a given module is available, its version, > and other metainformation about it.
Ihab Awad and I made an initial proposal for a module system for Harmony in January, and presented it to TC39. Proposal: http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v&hl=en Presentation: http://docs.google.com/Presentation?docid=dcd8d5dk_0cs639jg8&hl=en Since then, we've been working closely with a group called ServerJS that is creating a standard library for server-side JavaScript, with participants working on prototypes for {Spider,Trace}monkey (Flusspferd, GPSEE), V8 (v8cgi, k7), and Rhino (Helma NG, Persevere, Narwhal). They've converged on a module system specification that is very close in form to the initial phase of our proposal (that is, without syntactic sugar). The proposal and links to the relevant discussions, which have been extensive, are on the Moz wiki: https://wiki.mozilla.org/ServerJS/Modules/SecurableModules https://wiki.mozilla.org/ServerJS/Modules https://wiki.mozilla.org/ServerJS The proposal does not require augmentation to the global name space, but it might be desirable. In the proposal, there's a "require" free variable in the module, and various prototypes inject the free variable into the module's scope, some as an argument to the module factory function, some as a member of a fresh context object begotten of global. So, within modules, there's no need for a global variable. There are a couple known options for loading the "main", or initial module. One of them is to add a require method to the global object. Another is to introduce a variant of the <script> tag that loads a module instead of a global script. Chiron, my client-side prototype, uses a script tag to bootstrap a module loader and loads the module in the <script src> query string. Regarding feature testing, the module system might be useful since the "platform", albeit browser, could provide features as modules, in which case calling "require" on that module's identifier would throw an error. Some prototypes have a "require.isLoaded(id)" method that could be used to test whether modules provided by the platform have already been loaded, without having to catch a require error. However, these ideas probably don't obviate the need for a feature testing system for layout, rendering, event, and other features and quirks that might not be neatly distinguished based on the availability of a module. Kris Kowal _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
