Hi Logan - that's correct.
On Tue, Jun 2, 2015 at 11:08 PM Logan Smyth <loganfsmyth at gmail.com> wrote:
> To clarify things, since I don't think it's been made abundantly clear,
> the example that Sebastian gave would work in a standard ES6 environment,
> correct? It is only if the callback were executed synchronously that the
> exception would be thrown since the `this` binding has not yet been
> initialized?
> Transpilers however have elected to prevent this to err on the side of
> ensuring that invalid ES6 allowed through because adding runtime checking
> for the `this` binding would be difficult?
>
>
>
> On Tue, Jun 2, 2015 at 7:37 PM, Brendan Eich <brendan at mozilla.org> wrote:
>
>> With best intentions I must say that you are overreacting. The
>> subject-line code (h/t Mark Miller for pointing me at it!) in context of
>> the superclass constructor uses `this` before `super` has returned. That's
>> a no-no for pretty-good reason.
>>
>> If you have a better alternative design, we needed it last month. As
>> things stand, this is a thing to learn, with a workaround. What's the big
>> deal?
>>
>> /be
>>
>>
>> Matthew Robb wrote:
>>
>>> If I thought I could make any money then I would most definitely bet
>>> that the changes made to classes that are at the root of this problem will
>>> be the undoing of es classes and I find myself feeling more and more like
>>> avoiding them is the easiest thing to do.
>>>
>>> This use-case is a perfect example of something that is EXTREMELY
>>> unexpected which is funny because the changes are supposed to be supporting
>>> subclassing of built-ins.
>>>
>>> Very disheartened :(
>>>
>>>
>>> - Matthew Robb
>>>
>>> On Tue, Jun 2, 2015 at 6:43 PM, Domenic Denicola <d at domenic.me <mailto:
>>> d at domenic.me>> wrote:
>>>
>>> Hmm I am pretty sure Babel et al. are correct here in not allowing
>>> this. The super call needs to *finish* before you can use `this`.
>>> Chrome also works this way.
>>>
>>> The correct workaround is
>>>
>>> ```js
>>> let resolve, reject;
>>> super((a, b) => {
>>> resolve = a;
>>> reject = b;
>>> });
>>>
>>> // use this
>>> ```
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> 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
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150603/20a47470/attachment.html>
Hi Logan - that's correct. On Tue, Jun 2, 2015 at 11:08 PM Logan Smyth <loganfsmyth at gmail.com> wrote: > To clarify things, since I don't think it's been made abundantly clear, > the example that Sebastian gave would work in a standard ES6 environment, > correct? It is only if the callback were executed synchronously that the > exception would be thrown since the `this` binding has not yet been > initialized? > Transpilers however have elected to prevent this to err on the side of > ensuring that invalid ES6 allowed through because adding runtime checking > for the `this` binding would be difficult? > > > > On Tue, Jun 2, 2015 at 7:37 PM, Brendan Eich <brendan at mozilla.org> wrote: > >> With best intentions I must say that you are overreacting. The >> subject-line code (h/t Mark Miller for pointing me at it!) in context of >> the superclass constructor uses `this` before `super` has returned. That's >> a no-no for pretty-good reason. >> >> If you have a better alternative design, we needed it last month. As >> things stand, this is a thing to learn, with a workaround. What's the big >> deal? >> >> /be >> >> >> Matthew Robb wrote: >> >>> If I thought I could make any money then I would most definitely bet >>> that the changes made to classes that are at the root of this problem will >>> be the undoing of es classes and I find myself feeling more and more like >>> avoiding them is the easiest thing to do. >>> >>> This use-case is a perfect example of something that is EXTREMELY >>> unexpected which is funny because the changes are supposed to be supporting >>> subclassing of built-ins. >>> >>> Very disheartened :( >>> >>> >>> - Matthew Robb >>> >>> On Tue, Jun 2, 2015 at 6:43 PM, Domenic Denicola <d at domenic.me <mailto: >>> d at domenic.me>> wrote: >>> >>> Hmm I am pretty sure Babel et al. are correct here in not allowing >>> this. The super call needs to *finish* before you can use `this`. >>> Chrome also works this way. >>> >>> The correct workaround is >>> >>> ```js >>> let resolve, reject; >>> super((a, b) => { >>> resolve = a; >>> reject = b; >>> }); >>> >>> // use this >>> ``` >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> 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 >> > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150603/20a47470/attachment.html>