const {resolve} = Promise; // fails

[Andrea Giammarchi]

I guess one example would be more explicative: why cannot public static
methods be defined in a similar manner?

```js
const withLazyBoundObjects = new WeakMap;
const withLazyBoundMethods = obj => {
  const descriptors = Object.getOwnPropertyDescriptors(obj);
  Object.keys(descriptors).forEach(key => {
    const desc = descriptors[key];
    const {value} = desc;
    if (desc.configurable && typeof value === 'function') {
      delete desc.value;
      delete desc.writable;
      desc.get = function (...args) {
        let methods = withLazyBoundObjects.get(this || obj);
        if (!methods)
          withLazyBoundObjects.set(this, methods = Object.create(null));
        return methods[key] || (methods[key] = value.bind(this));
      };
    }
  });
  return Object.defineProperties(obj, descriptors);
};

// example
const {resolve, reject} = withLazyBoundMethods(Promise);
resolve(123).then(console.log);
```

On Thu, Jul 19, 2018 at 4:33 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> sorry, that'd be `public get resolve()` and also `public #resolve()` so
> nobody should be confused about the fact I'm talking about public static
> methods.
>
> On Thu, Jul 19, 2018 at 4:32 PM Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> 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/b9e4bd50/attachment.html>