Native modules

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
> OR
> 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
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100119/3ec9e544/attachment.html>


More information about the es-discuss mailing list