Comments on Meeting Notes
khs4473 at gmail.com
Tue Dec 4 08:54:21 PST 2012
=== @names ===
I think punting on @name syntax until ES7 is a wise move. I would like to
sneak in a word of clarification on my modular @name proposal, though. In
my proposal, @names are not "implicitly declared" variables. They are
namespaced identifiers, where the namespace container is the module URL.
They are static in the sense that all @names can be mapped to a globally
unique string (module URL + identifier) prior to execution.
Modular @names are not simply veneer over symbols. They provide a separate
facility (non-conflicting property names) which happens to use unique
symbols as an implementation strategy. It could perhaps also use globally
In my opinion, we should not go with bracketed, computed property names
*solely* for the support of the iterator protocol. Ultimately, I would
recommend a more conservative approach for ES6: use the plain string
"iterator" as the protocol hook. Once the syntactic issues have been
addressed in ES7, future language hooks can use unique symbols. Give the
user base some time to digest symbols, and see where the cows roam before
adding syntax directing them. There is more than enough new "stuff" in
ES6, without having to rewrite everything in terms of symbols (just yet).
=== let ===
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible path. Strict mode only has a bad reputation
because, in ES5, it is restrictive-only. There are (almost) no carrots
leading users there. Leave non-strict as is, and let users opt-in to
"let". An excellent carrot.
=== Modules ===
Perhaps I'm misreading the notes, but I am concerned about the amount of
churn that I'm seeing in module discussions. Particularly worrisome to me
is the suggestion that the default loading behavior should map:
import x from "foo";
System.baseURL + "foo" + ".js"
This is contrary to all url resolution algorithms on the web, and involves
way too much magic.
In general, I would like to see more updates and more convergence regarding
the modules specification, as many of us are now aiming at a (seemingly)
wildly moving target.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss