On May 11, 2009, at 4:10 PM, Kris Kowal wrote:
I agree about mixing metaphors. The befuddlement of start : stop :: begin : end is one that bothers me a lot. The notion is to desugar "import" and "export" to these two facets, importing and exporting. imports : exports would be proper, but doesn't read well in code. The reason for using the term "exports" is to ease migration, since:exports.a = function a() {}; Is easy to transform textually to: export a = function a() {};
Hmm, that cuts both ways. You can run a sed script or whatever, but if skimming or otherwise manually inspecting (humans are error-prone ;-) the difference is slight.
So, I'm inclined to stick with "exports" instead of "provide". The
metaphor would be complete if we used "imports(id)" or "import(id)".
Since "import" is a keyword, it would not be available for the
desugarred syntax. That leaves "imports".
const {a} = imports("module");
Kinda works, yeah.
What makes functions eval'ed hermetically by the module function occur in astatement context? They should be nested function declarations, not (sub-)statements. Or I'm missing something.Perhaps I'm behind on the times, but I'm under the impression that presently the behavior of this function "foo" declaration has no standard behavior: (function () { function foo() { } })();
No, that's fully specified by ES3.
If foo gets bound in function block scope, there's no problem (which is the case in most browsers, I believe), but if it gets bound as a member of global, that would be a problem,
I know of no such bug. You might be thinking of a different IE bug, where named function expressions are evaluated to bind their names in the variable object.
and if it gets bound like a free assignment, it would only be a problem if free assignment isn't localized to the module somehow.
No such bug in any implementation I've ever seen or heard of.
Implementations would need to decouple the top of the scope chain andthe global object.Implementations can do this easily, but the issue is language- level: is theglobal object at the bottom of the scope chain? So far, it is.I've operated on the assumption that the global object was on the bottom of the scope chain. There are some concerns about module texts for parsing and interpreting modules, some of which might be sufficiently addressed by moving global off the scope chain for module evaluation, but perhaps not necessarily.
Sounds like "use lexical scope" or (as the proposal happily allows) something subsuming it would do the trick, and provide other benefits.
* free assignment. I'm less concerned about the behavior of free assignment. I'd prefer assignment to global to be explicit, but this ship may have sailed long ago. It might be more appropriate for free assignment to create module locals or module exports, which could be accomplished by changing the bottom-of-the-scope-chain, or by changing the behavior of free assignment in the context of a hermetic eval. In any case, this is not something I'm deeply concerned with.
ES5 strict mode makes free variable creation via assignment an error, so let's roll with that.
* function statements. These really must be module local. I'm not in-the-know about whether this is a problem or not.
Not a problem.
* return statement. This should be a parse error in the top most scope of a module. If hermetic eval wraps a module's text in a function declaration, the return statement would not be a parse error, which would be a problem.
The only way around this with existing tools is to eval the string body of the module-function, which will again make return a parse error. Double eval overhead.
If heremetic eval returns a function that executes the module with a given require and exports object, then return would be a parse error in the bottom-scope.
I don't follow this sentence.
* injection attack strings. These are a weakness of using a hermetic eval that immediately evaluates a module factory function expression with the module text inside.
ASTs to the rescue? This just moves the injection attack surface, arguably shrinks it a good deal by breaking eval up into parse + execute (let's call it).
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
