Until ES7. If we try to solve all problems in ES6, it might not ship
earlier than ES7 anyway.
On Mon, Dec 3, 2012 at 4:38 PM, Domenic Denicola
<dome...@domenicdenicola.com> wrote:
> 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
> Sent: 12/3/2012 18:00
> To: es-discuss discussion
> 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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
