On dropping @names

Brandon Benvie brandon at brandonbenvie.com
Mon Dec 3 14:59:55 PST 2012


>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121203/63246bd8/attachment-0001.html>


More information about the es-discuss mailing list