Comments on Meeting Notes

Herby Vojčík herby at mailbox.sk
Tue Dec 4 09:15:41 PST 2012



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


More information about the es-discuss mailing list