Comments on Sept Meeting Notes

Brendan Eich brendan at mozilla.com
Fri Sep 27 17:44:52 PDT 2013


> Waldemar Horwat <mailto:waldemar at google.com>
> September 27, 2013 3:45 PM
>
>
> It's even back in ES6 with "then".  I find it truly weird that we're 
> trying to use two different mechanisms to get the <then> and <iterate> 
> metaproperties.  We should be cutting down the complexity, not adding 
> to it in a manner which the unknowns bouncing around this thread 
> indicate is reckless.

You have a point. Indeed Jason Orendorff urged us to use 'iterator', not 
an @@iterator symbol, to name the unstratified trap for the iteration 
protocol. But he lost, since we are in new territory and have a chance 
to avoid collisions.

Not so with promises, which *want* 'then' to name the duck-typed method. 
That's an API cowpath the cows have already trod, indeed almost paved 
(with what topping, I won't say ;-).

/be
>
>     Waldemar
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Yehuda Katz <mailto:wycats at gmail.com>
> September 26, 2013 4:22 PM
> On Thu, Sep 26, 2013 at 4:20 PM, Allen Wirfs-Brock 
> <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>
>
>     On Sep 26, 2013, at 4:12 PM, Brandon Benvie wrote:
>
>     > On 9/26/2013 4:09 PM, Allen Wirfs-Brock wrote:
>     >> The newness was using using string literals+ concise methods to
>     write such meta=level methods.
>     >>
>     >> What it brings to the table is that it address the meta
>     stratification issue in a reasonable manner without having to add
>     anything (other than the use of the hooks) to the ES5 level
>     language.  (and I'm ignoring the enumerability issues).
>     >
>     > I don't see how any of the string key proposals so far are
>     different from __proto__, which we agree is not an adequate level
>     of stratification (none basically).
>
>     It moves the stratified names out of the syntactic space that JS
>     programmers typically use for their own names.  The Dunder names
>     don't have that characteristics plus various sort of "_" prefixing
>     is already used by many programmer at the application level.
>
>
> Agreed, but this problem will come right back in ES7. Private names 
> don't solve this issue because of where they trap, so we don't need a 
> temporary patch, but a permanent solution.
>
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> September 26, 2013 4:20 PM
>
> It moves the stratified names out of the syntactic space that JS 
> programmers typically use for their own names. The Dunder names don't 
> have that characteristics plus various sort of "_" prefixing is 
> already used by many programmer at the application level.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Brandon Benvie <mailto:bbenvie at mozilla.com>
> September 26, 2013 4:12 PM
>
>
> I don't see how any of the string key proposals so far are different 
> from __proto__, which we agree is not an adequate level of 
> stratification (none basically).
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> September 26, 2013 4:09 PM
>
>
>
> The newness was using using string literals+ concise methods to write 
> such meta=level methods.
>
> What it brings to the table is that it address the meta stratification 
> issue in a reasonable manner without having to add anything (other 
> than the use of the hooks) to the ES5 level language.  (and I'm 
> ignoring the enumerability issues).
>
> There is significant semantic complexity that Symbols add (I know, I 
> just did all the work again).  The possibility of avoiding that added 
> complexity is worth a little bit of exploration.
>
> Allen
>


More information about the es-discuss mailing list