Mark S. Miller
erights at google.com
Tue Jan 19 13:07:00 PST 2010
On Tue, Jan 19, 2010 at 12:25 PM, Kevin Curtis <kevinc1846 at googlemail.com>wrote:
> Maybe 'native modules' is the wrong term. The issue is maybe more to do
> with finding a namespace home for new native functionality. Namespaces have
> some overlap with modules (i think).
> Whenever a new bit of native platform functionality needs to be exposed to
> ECMAScript there is a debate about where to bind it. Global? Object? Could
> the import syntax assist with this. e.g.
> import #math2 // special import syntax for native math functionality
> const math2 = services.get("math2"); // request a native service
I think this is an excellent suggestion. Weak pointers, Ephemeron tables,
and catchalls are all on the table for the january mtg (<
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references> and <
http://wiki.ecmascript.org/doku.php?id=strawman:proxies>). Pending a modules
proposal, these purposely postpone the question of how their new start
objects -- WeakPtr, EphemeronTable, and Proxy -- come into scope. For
EphemeronTable and Proxy, since they provide neither new source of authority
nor of non-determinism,
const EphemeronTable = import 'sys/EphemeronTable';
const Proxy = import 'sys/Proxy';
or something seems reasonable, modulo what the package names should be. For
WeakPtr, since it provides a new source of non-determinism, it needs not to
be available by default to SES code, but rather, only at the discretion of
its sandboxing environment. I think this distinction is an interesting use
case for the module proposals to examine.
> Python has 'native modules' built in to the runtime (not dynamically loaded
> extension modules) which are not in the global top-level namespace. They
> must be explicitly imported via the import command. So the 'import' command
> covers importing both pure python modules and built-in 'native modules'.
> Note: i am definitely not talking about dynamically loading native code
> into the browser over the web. Just a way of exposing additional native
> functionality - without dumping it in the global namespace or Object.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss