Native modules

ihab.awad at gmail.com ihab.awad at gmail.com
Tue Jan 19 13:40:59 PST 2010


On Tue, Jan 19, 2010 at 1:07 PM, Mark S. Miller <erights at google.com> wrote:
> I think this is an excellent suggestion. Weak pointers, Ephemeron tables,
> and catchalls are all on the table for the january mtg. 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.

My response assumes the further constraint that some other
functionality (e.g., Parser) may be provided as a pure-ES module at
some point, then migrated into the runtime later on, and clients of
Parser might want to be insulated from this change.

In my proposal, I mention a "platform import-module" object, "pim".
This is the root of the importing chain and its API is unspecified by
my proposal (though it might be later on).

This object may allow its creator to specify "overlays" of part of the
module namespace. In other words:

  myNewPim = pim.withOverlay({
      'sys/foo': import 'fooImpl' from { /* some package */ },
      'sys/bar': import 'barEmulator' from { /* some package */ }
  });

This should fail immediately if any of the overlaid objects is not an
(authority-free) module function. All module functions loaded by
"import" are stamped as such, as are native pieces of authority-free
functionality provided by the interpreter.

The "pim" provided by an interpreter will come pre-populated with
overlays for the appropriate functionality the interpreter provides.

As for where to supply that "pim" and other, authority-bearing
objects: that is a "service registry" question and is out of scope for
the module system.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA


More information about the es-discuss mailing list