On dropping @names

David Herman dherman at mozilla.com
Mon Dec 3 17:39:07 PST 2012

I think the important thing to recognize is that @names was an *extremely* late proposal, and it's just way too late for ES6, but that doesn't at all mean it's out for good. The deadline for new features was in the spring of *2011* after all! Now, the fact that we considered it at all was due to the fact that we were concerned about the same things you're concerned about here. But we have a lot to get done for ES6, and there are just too many questions related to @names to put them in at this late stage.

In other words, they're not rejected, they're just not happening for ES6.


On Dec 3, 2012, at 2:59 PM, Brandon Benvie <brandon at brandonbenvie.com> wrote:

> From the meeting notes it appears that support for @names is out, which I believe is quite unfortunate. I'd like to either propose a way to resolve the issues that caused them to be dropped, or come to an understanding of what the reason is that they can't be resurrected.
> First, I wanted to touch on the hypothetical "do I have to look up in scope to know what prop means in { prop: val }". Without @names Symbols are "eternally computed" despite actually being specific values that are statically resolvable. From the debugging standpoint, there's not actually a way to usefully represent properties with symbol keys. Furthermore, there's no way definitively look at source code and be able to determine when a property has a string key or a symbol. The only way you can is if you can trace back to the original `import Symbol from '@symbol'` used to create the value associated with a given variable.  This is the same problem, but even worse because without the '@' it can't even be determined if something is a string or a symbol, not just what symbol it is.
> Unless I'm not interpreting the correct meaning from the notes, the assertion was made that @names aren't static. My reading of the proposal indicates that you can only declare an @name once in a given scope and that you can only assign to it in the declaration. The only hazard that this creates is that it's possible to end up with one Symbol that's assigned to more than one @name in a given scope. In all other cases they behave as expected. Having @name declarations shadow outer ones is the same behavior as any other declaration and that's expected behavior.
> To address the problem with one symbol initializing multiple @names, @name initialization should be limited to the bare minimum. The main (only?) reason @name declarations needed an initializer is to facilitate importing them. If  @name initialization was limited to import declarations then a duplicate check during module loading results in the desired static runtime semantics.
> Using the MultiMap functional spec from Tab Atkins earlier today, I created a side by side comparison with and without @names. https://gist.github.com/4198745. Not having syntactic support for Symbols is a tough pill to swallow. Using Symbols as computed values with no special identifying characteristics results is significantly reduced code readability. Really ugly code, in fact.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list