That's certainly a clever solution, but one without precedent in the language. It also means you can't `Promise.resolve.call(SubPromise)`, although perhaps you could avoid that by skipping `.bind` and creating a normal function wrapper inside the getter - I'm curious how that might be implemented as well as specified.
On Thu, Jul 19, 2018 at 4:54 PM, Andrea Giammarchi < [email protected]> wrote: > 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> > Le 19 juil. 2018 à 16:32, Andrea Giammarchi < >>>>>> [email protected]> 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 >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
