Yehuda Katz (2013-09-26T23:15:11.000Z)
On Thu, Sep 26, 2013 at 4:12 PM, Brandon Benvie <bbenvie at mozilla.com> 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).


Indeed. The reason dunder doesn't work is that it's used in user-land due
to the spec's usage, which means that it's not implausible that some
library uses __iterator__ already for a different (or even similar) purpose.

The @ prefix dodged that bullet today (although it may introduce
generated-code hazards), but it opens up exactly the same problem for the *
next* time we need a new unique name.


>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/f27f8473/attachment.html>
domenic at domenicdenicola.com (2013-10-13T02:34:25.575Z)
On Thu, Sep 26, 2013 at 4:12 PM, Brandon Benvie <bbenvie at mozilla.com> wrote:

> 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).


Indeed. The reason dunder doesn't work is that it's used in user-land due
to the spec's usage, which means that it's not implausible that some
library uses `__iterator__` already for a different (or even similar) purpose.

The @ prefix dodged that bullet today (although it may introduce
generated-code hazards), but it opens up exactly the same problem for the *next* time we need a new unique name.