It seems like, at least in the case with Promise, it could be solved also
by having the this binding of the executor bound to the promise or have the
promise object passed into the executor as a third argument maybe?
On Jun 2, 2015 10:38 PM, "Brendan Eich" <bren...@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...@domenic.me <mailto:
>> d...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
