Native modules

Kevin Curtis kevinc1846 at googlemail.com
Wed Jan 20 12:04:23 PST 2010


Native functionality/services or captabilities can be either part of the ES
enviroment (JSON) or the platform browser (XMLHttpRequest).

At the moment the global object acts as the "service registry". All native
services get dumped there.

The global object seems to have a couple of functions:
- exposing native functionality (or capabilities) in a "dependency injection
container" fashion.
- passing 'global vars' between scripts tags.

So, a lot depends on what the role of the global object is in the future.
Will it continue as container/provider of services/capabilities? With
top-level ES code then parceling out the capabilities to modules.
Or is there something else in the pipeline?

It's interesting to ask (as Ihab alluded to) if the module system was in
place how would the evolution of JSON object happened from pure ES to a
'native module'.

A crude idea:
"use strict sys"
const pim = sys.pim;
// sys acts as the root for exposing additional core native functionality.
// import is just for pure ES

This dicussion on how to expose native platform functionality - securely -
to ES in a HTML5 context is interesting:
http://arstechnica.com/business/news/2010/01/chrome-os-interview-1.ars/3
See section 'Programming Nuts and Blots'. A bit OT - but related to
namespaces and maybe modules.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100120/b967e7c2/attachment.html>


More information about the es-discuss mailing list