Kevin Smith wrote:
=== @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 unique strings... In my opinion, we should not go with bracketed, computed property names *solely* for the support of the iterator protocol. Ultimately, I would
+1
recommend a more conservative approach for ES6: use the plain string "iterator" as the protocol hook. Once the syntactic issues have been
I'd say not "iterator". This is a special identifier, so to speak "instead-of-symbol-internal-name", so I would go for __iterator__. Same for other few examples which may have benefited from symbols but cannot.
It would create consistent __legacy__ realm where each member should be obsoleted by evangelizing the right way once it appears (__proto__ won't have one, it is too stuck; __{define|lookup}{Getter|Setter}__ already have the right way; it can be same for __iterator__, __create__, __hasInstance__ etc.).
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.
I would agree. But there would be a fight of what else should only be strict-mode, since it is simpler to do it that way. Then there comes 1JS, and refactoring concerns, and a lot more, probably.
- Kevin
Herby _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
