Export Objects

[caridy]

Tagline: Formalizing a reflective API to create export bindings for Reflective Module Records.

Details

• Removing the confusing mutator in favor of re-usable Export Objects
• Reflect.Module.Export.let()
• Reflect.Module.Export.var()
• Reflect.Module.Export.const()
• Reflect.Module.Export.from()

Usage

import * as fs from "fs";

var Export = Reflect.Module.Export;

var y, TAU;

// reflective API takes Export objects to represent each export slot
var mod = new Reflect.Module({
  // initialized mutable (includes "uninitialized" var)
  x: Export.var(),
  y: (y = Export.var(42)),

  // uninitialized mutable (let, class)
  z: Export.let(),

  // initialized immutable (const)
  PI: Export.const(Math.PI),

  // uninitialized immutable (const)
  TAU: (TAU = Export.const()),

  // indirect binding from arbitrary object
  bar: Export.from(delegate, "bar"), // optimizable special case; helps interop with existing module systems

  // re-export (heavily optimizable since `fs` is known to be a module namespace object)
  readFile: Export.from(fs, "readFile")
});

console.log(mod.y); // 42
y.set(43);          // mutates the y slot
console.log(mod.y); // 43
TAU.get();          // throws TDZ error

Re-exporing all from Module

function exportAllFrom(ns) {
  let o = Object.create(null);
  Object.keys(ns).forEach(key => {
    o[key] = Reflect.Module.Export.from(ns, key);
  });
  return Reflect.Module(o);
} // this return a new namespace object for the new reflective module that was created from the namespace argument.

Node Compat-Mode

function exportAllFromCJS(cjs) {
  let o = Object.create(null);
  Object.keys(cjs).forEach(key => {
    o[key] = Reflect.Module.Export.let(cjs[key]);
  });
  return Reflect.Module(o);
} // this return a new namespace object for the new reflective module that was created from the cjs module argument.

Rendered HTML

https://rawgit.com/caridy/6430042924e0436918ea/raw/0f9e2224f1c29ac4449000f5350fdcb2ae439157/loader-pr129.html

[caridy]

/cc @dherman @wycats

[caridy]

it is not longer stored directly in the env record, but it is accessible from there.

[rektide]

I'm curious what happened to the descriptors? Why is the API all now exporting objects, no descriptors? It seems like it'd be handy to be handy to be able to getter/setters.

[caridy]

@rektide the descriptors we had before were not object property descriptors, they were export descriptors.

As for getter/setter, we have been drilling on the requirements, eventually we will provide that as a new feature, but that will require spec changes in 262 and discussions with implementers (which we have done some already), which will take longer.

[caridy]

We have decided to maintain the old API (export descriptors). Few thoughts:

• it reflects better the construction of a source text module record
• the extra machinery for the special "export module record" is a no-go
• Export api has probably better ergonomics, but this is not intended for citizen developers, but low level (libraries and fw) code.
• Export doesn't give us the edge we thought in terms of functionalities, everything could be replicated with the export descriptors in the same way you would get it done using declarative syntax.

note: there are few editorial things from this PR that we will cherry-pick

[caridy]

@dherman did I missed anything else here?