-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional complexity you could remove from Promises #5
Comments
Importantly, do you feel removal for such delegation-by-property-lookup is web compatible for Promises? Is your intuition that such delegation is exceedingly rare, like in the case of similar machinery for RegExps? |
Yes, that's my intuition. Although I can find a few promise subclass packages on npm, I can't see any signs of life on them, and I've never heard of any promises being subclassed in the wild. (Also, of those npm packages, none of them seem to override |
@domenic I personally answered question how to abuse |
fwiw, I'm pretty certain none of this complexity removal would break any Promise shims - either the entire functionality or |
I do want to note that Mithril does rely on I didn't put that particular aspect in the API - the framework's original author did. Problem is, a large portion of the community likes it, and I need a good alternative to exist or my hand forced somehow (like via this proposal) before I can finally remove it. |
I just used subclassing Promise days ago like this: class X extends Promise {
constructor(e) { super(e); super.catch(console.warn); }
static get [Symbol.species]() { return Promise }
} |
You could replace all of that with a constructor that does |
Not quite though. Returning the chained promise would swallow errors. |
@Jack-Works In either case, you could still just use an ES5 function to accomplish almost the same effect: function X(...args) {
const p = new Promise(...args)
p.catch(console.warn)
return p
} As for how each type would affect you if you wanted to update your code and you don't care about
|
I'd also note that the semantics proposed here would leave @Jack-Works 's code working exactly as it does today. The only thing it would change is what happens if you don't override |
And without specifying species, it becomes a deadloop |
To clarify, I'm saying, if we make it so that |
The same as #23. The generic nature of Even with a polyfilled |
@zloirock Not sure that polyfill would break the non-generic detection or the species detection - it'd just silently start adding it back in every modern browser. Of course that'd need fixed in core-js, but devs would have to update core-js before they'd notice anything different. |
@isiahmeadows seems you didn't read #23. Yes, you could say that it will not break the most methods - they will not stop work - they just will be tens and hundreds of times slower - I think that it could be called "breaking". But some cases will be completely broken - for example, I'm too lazy to come up with complex cases related directly to this issue, so the most simple. For example, since Do you really think that you could say all developers immediately update their dependencies? -) I already wrote that |
Okay, I meant functionally non-breaking, not "broken" because it's slow. (That's of course a whole separate issue, and if that's the case, I'd love to stand corrected.) I did look at the source and now I see some risk of breakage, specifically when running in V8: https://github.com/zloirock/core-js/blob/49f13bfbfb4a48fe82d178df58fc943103e24997/packages/core-js/modules/es.promise.js#L65-L68 I'll stand corrected on this criticism now - that bit of code gives me a little bit of pause.
Do you have a link to the relevant source? It'd be very strange for
I'm not saying developers would immediately update their dependencies - I was in fact trying to say I didn't think they would need to. |
Seems you didn't understand the source of this feature detection. In the modern V8 it will not be replaced because of this line so in V8 the number of problem cases reduced. But only in V8 and with recent
It's too many places - see the source code of feature detections and export logic, the explanation why - above. Some methods will work in the global
In the polyfill, but not in the native method which will be used - it does not include any feature detection. |
Adding subclassing support to promises, with all its attendant complexity, is one of my greatest regrets. I'm very excited about the possibility of fixing that.
This proposal doesn't go as far as it could in removing the complexity that I added. Here are some additional things that could be done:
@@species
]..then
, a lot of error checking can be removed. (Including, I think, [[AlreadyCalled]].)this.resolve
.More insight might be gathered by looking at some of the commits from the original ES6 promises spec draft that introduced all this subclassing complexity:
The text was updated successfully, but these errors were encountered: