On Feb 1, 2010, at 9:21 AM, Sam Tobin-Hochstadt wrote:
On Mon, Feb 1, 2010 at 1:04 AM, <[email protected]> wrote:
But, in some module M that imports X, Y and Z, the top-level lexical
environment *must* include access to all the state encapsulated by X,
Y and Z.
That's only the case if X, Y, and Z provide access to their internal
state via the bindings they export. For example:
module MemoFun {
var table = {};
export function f(x) {
if table[x] { return table[x]; }
// imagine complex but pure computation here
var tmp = x + 7;
table[x] = tmp;
return tmp;
}
}
Here, the only access provided to the state is via the function `f'.
Outside modules cannot disturb the invariants of the code at all.
This is a crucial point, probably worth repeating: each module has its
own lexical binding environment at its top level, not a global object.
In the Harmony era wiki, this idea goes back at least as far as
http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope
As in the "use lexical scope" proposal, the new syntax of |module id
{...}| changes the rules within the braces: no more global object.
In any case, my point stands. The namespaces for "pure code being
brought in" and "powers granted to me by my container" are being
conflated. For the former, you need modules. For the latter, you need
some sort of "service registry" or whatever else.
I think that in many cases, conflating these two concepts is
appropriate. For example, if I import jQuery to add some simple bit
of functionality to my homepage, I almost certainly want to give it
access to all of the things I have access to. This is the common case
that our strawman tries to make simple. However, in other contexts a
service registry may be more appropriate, and that can be built on top
of modules, using either the dynamic loading features, or simple
lexical scope with functions and objects.
Another point worth highlighting: simple and common (and safe in their
own terms) chores should be easy to write; more complex use-cases
should be possible, while obviously less simple to express. Doing it
the other way 'round, requiring the more complex forms to do simple
thigns, overcomplicates the language.
The pitfall of having to do everything today on extant browsers using
first class functions and objects (and code generators) should not
dictate complexity for all use-cases in the integrated module system.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
