const {resolve} = Promise; // fails

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Jul 19 23:54:21 UTC 2018


My code doesn't suffer what Domenic says.

Once again:

```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);
};

// patch the Promise
withLazyBoundMethods(Promise);

// have a class that extends Promise
class SubPromise extends Promise {}

// test inheritance
SubPromise.resolve() instanceof SubPromise; // true
(0,SubPromise.resolve)() instanceof SubPromise; // true

// even the Promise ?
Promise.resolve() instanceof SubPromise; // false, it's Promise
(0,Promise.resolve)() instanceof SubPromise; // false, it's Promise
```

So, why cannot we have above behavior in core?



On Fri, Jul 20, 2018 at 1:36 AM Jordan Harband <ljharb at gmail.com> wrote:

> > TL;DR why aren't public static methods that need context **all** lazily
> defined as bound (once) on demand? That would make every single public
> static method consistent, accordingly with the Class you extracted them
> from, right? That's not clever, that's usually developers expectations
> because historically all public static methods don't need the Class to work.
>
> I believe
> https://github.com/tc39/ecma262/issues/544#issuecomment-236487230 answers
> this - specifically, expressing that the claimed better design is for
> *nothing* to be bound.
>
> On Thu, Jul 19, 2018 at 4:22 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> Reading that looks like nobody answered my question, explained through
>> some code that wouldn't have any issue with subclassing.
>>
>> So no, there's no answer to my latest question in there, unless I've
>> missed it.
>>
>> On Thu, Jul 19, 2018 at 7:56 PM Jordan Harband <ljharb at gmail.com> wrote:
>>
>>> This question has been answered here:
>>> https://github.com/tc39/ecma262/issues/544
>>>
>>> On Thu, Jul 19, 2018 at 9:27 AM, Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>
>>>> > Per the KISS principle, let’s avoid to be clever.
>>>>
>>>> I think my next code example is less clever, but the only reason I've
>>>> written hacks or code was not to be advocated or adopted, just to explain
>>>> what could happen internally.
>>>>
>>>> TL;DR why aren't public static methods that need context **all** lazily
>>>> defined as bound (once) on demand? That would make every single public
>>>> static method consistent, accordingly with the Class you extracted them
>>>> from, right? That's not clever, that's usually developers expectations
>>>> because historically all public static methods don't need the Class to work.
>>>>
>>>> On Thu, Jul 19, 2018 at 5:23 PM Claude Pache <claude.pache at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> > Le 19 juil. 2018 à 16:32, Andrea Giammarchi <
>>>>> andrea.giammarchi at gmail.com> a écrit :
>>>>> >
>>>>> > 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 ?
>>>>> >
>>>>>
>>>>> Nice hack... But it imposes all subclasses of `Promise` that override
>>>>> the `resolve` method to use a similar trick, because the following will
>>>>> break:
>>>>>
>>>>> ```js
>>>>> class MyPromise extends Promise {
>>>>>     static resolve() {
>>>>>         // do fancy stuff
>>>>>         return super.resolve()
>>>>>     }
>>>>> }
>>>>>
>>>>> const {resolve} = MyPromise
>>>>>
>>>>> resolve() // TypeError: undefined is not an object
>>>>> ```
>>>>>
>>>>> Per the KISS principle, let’s avoid to be clever.
>>>>>
>>>>> —Claude
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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/20180720/528b355d/attachment-0001.html>


More information about the es-discuss mailing list