Update to newest module proposal

[domenic]

http://wiki.ecmascript.org/doku.php?id=harmony:modules has changed drastically as of about a month ago.

[matthewrobb]

I'm aware. Do you know if there is any intention to look at the alternative proposals thrown about in the last couple months? It seemed far from settled after this was published in the latest version of the spec.

Also, I recently moved myself and my family from the east coast to the west coast and have not had much time to put in to this project. I am hoping to get back in to it soon.

Funny you posted this issue tonight as I actually looked through the es-discuss threads and at the wiki to see if there was any indication that I should wait on the new module syntax with no conclusions. I guess I should assume it's safe to move forward as currently published.

[domenic]

Well, I think it is honestly still in flux. I personally hope things get changed in a few ways. But there's nothing conclusive yet, and if it's not that much extra work, I think being up to date would help, since you'd be ahead of Traceur et al. :D

From what I can see here are the major changes you'd want to make:

module path = "path";

// becomes

import "path" as path;

import dirname from fs;
import local_function from "./local.js";

// becomes

import { dirname } from fs;
import { local_function } from "./local.js";

and add

export = <expression>;

(which is one of the things I think will change into some nicer syntax, e.g. export only <expression>.)

---

Another major change you might try is to get the correct semantics for aliased bindings, as discussed in es-discuss. That would involve rewriting to temporary variables, e.g.

import { state, modifyState } from "foo";

assert(state === 5);
modifyState();
assert(state === 10);

transpiles to

var $___foo = require("foo");

assert($___foo.state === 5);
$___foo.modifyState();
assert($___foo.state === 10);

I hope TC39 decides against these crazy semantics, but it seems like they've been using them ever since first conceiving of a module proposal, and so are unlikely to change their mind.

[matthewrobb]

@domenic From my understanding of the wiki, modules export immutable bindings. If I understand you correctly above, calling a shared export that mutates a binding SHOULD be reflected in imported bindings as well? Like magic javascript pointers?

[domenic]

@matthewrobb that is my understanding as well. I will ask es-discuss, as it seems like this semantic is not transpilable...

[domenic]

Oh right, I remember. You're supposed to transpile to a bunch of getters, implemented on an entirely virtual object, which delegate back to the mutable parent.

---

Also, export = and import as are dead as of the last TC39 meeting, so that reduces the workload. So much churn!

[matthewrobb]

I really wish there were some proposed API's to support grokkability of es6 modules. For example if modules create a frozen object of getters then that would practically look something like:

var mutableExports = { exportA:{}, exportB:{} };
var immutableCopy = Object.freeze({
   get exportA: function(){ return mutableExports.exportA },
   get exportB: function(){ return mutableExports.exportB }
});

Where you hand off immutable copies. Considering that every module has a unique context then what I'd like to see is something like:

var localBinding = {};
Object.defineExport(this, "exportC", ()=> localBinding);

Basically I think it should be possible to explain in non-webster english what a module (the thing you end up interacting with in your code) actually is. I also think it should be backed as much as possible by non-new syntax API's even if implementing those API's in modern js engines isn't possible.

Basically getters/setters/property descriptors weren't possible in js prior to es5 but that didn't stop the language from getting both of these:

var name = {}, obj = { get name(){ return name; } };
Object.defineProperty({}, "name", { get: function(){ return name; } }