const {resolve} = Promise; // fails

[Andrea Giammarchi]

I know it's about subclassing, which is why I've asked why, once there's no
context, the default/base one is not considered, but since everyone came
back with the subclassing issue, which is actually what I've said myself on
twitter about the current state, how about changing all public static
methods that need it, to be getters ?

```js
class Promise {
  #resolve(...args) {
    return this.nativeImplementation(...args);
  }
  get resolve() {
    return #resolve.bind(this);
  }
}
```

we could argue `Promise.resolve === Promise.resolve` should be preserved,
as behavior, so that we need a lazy defined getter ... **but** why not
making public static restructuring from known constructors work regardless,
under all circumstances ?


On Thu, Jul 19, 2018 at 4:11 PM T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:

> On Thu, Jul 19, 2018 at 12:56 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > Why cannot Promise methods fallback to Promise constructor when the
> > class/context is not available?
>
> That sounds reasonable on first glance, but I'd be concerned about what
> happens when you do it after subclassing:
>
> ```js
> class MyPromise extends Promise {
>     // ...and adds some important feature...
> }
> // ...
> const {resolve, reject} = MyPromise;
> const p = resolve();
> p.someImportantFeature(/*...*/); // TypeError: undefined is not a function
> ```
>
> ...since `resolve` fell back to `Promise`. That feels like a footgun.
> Either subclassers would have to handle that, which they will forget to do,
> or it has to be a bit more complicated than just a simple fallback to `
> Promise` (I don't immediately know what that "more complicated" answer
> would be.)
>
> -- T.J. Crowder
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180719/c87fbb92/attachment.html>