const {resolve} = Promise; // fails

[Andrea Giammarchi]

Yes Michael, the `::` operator is the best thing ever proposed and got
killed / pseudo replaced by another, completely different, operator that
won't solve problems `::` would: the `|>` pipe one.

I'm a big fan of the `::` operator, and if it were there, I would quite
possibly also like the "per context" restructuring.



On Thu, Jul 19, 2018 at 5:12 PM Michael Luder-Rosefield <
rosyatrandom at gmail.com> wrote:

> At this point I can't ignore how much overlap there is between this and
> the this-binding operator proposal
> https://github.com/tc39/proposal-bind-operator
>
> ```
> const resolve = ::Promise.resolve; // takes and binds
> ```
>
> As someone who often extracts functions with deconstruction, I'd love for
> there to be an extension to this proposal to handle this case.
>
> ```
> const { resolve, reject } = ::Promise; // ?
> ```
>
> That would leave the question though of what to do with nesting:
>
> ```
> const { fn1, foo: { fn2 } } = ::bar; // fn1 is bound to bar. Is fn2 bound
> to bar, or foo?
> ```
>
> On Thu, 19 Jul 2018 at 15:58 Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> 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
>>>>>
>>>>> _______________________________________________
>> 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/20180719/0edf6a80/attachment-0001.html>