On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that the typical iterator form will
be something like:
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
________________________________
From: Brandon Benvie<mailto:[email protected]>
Sent: 12/3/2012 18:00
To: es-discuss discussion<mailto:[email protected]>
Subject: On dropping @names
>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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
