lib: use safe methods from primordials by targos · Pull Request #27096 · nodejs/node (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation13 Commits3 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This changes the primordials to expose built-in prototypes with their
methods already uncurried.
The uncurryThis function is therefore moved to the primordials.
All uses of uncurryThis on built-ins are changed to import the relevant
prototypes from primordials.
All uses of Function.call.bind are also changed to use primordials.
This changes the primordials to expose built-in prototypes with their methods already uncurried. The uncurryThis function is therefore moved to the primordials. All uses of uncurryThis on built-ins are changed to import the relevant prototypes from primordials. All uses of Function.call.bind are also changed to use primordials.
Co-Authored-By: targos targos@protonmail.com
PRs that have at least one approval, no pending requests for changes, and a CI started.
label
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I borrowed the term primordials from the realms proposal, I believe it makes sense to have your own primordials other than the JS builtins? But anyway that's just academic..
Does this affect performance at all? From what I can tell this does not seem to be on any path that's performance-sensitive, though.
Does this affect performance at all?
I don't know which one is faster between Function.call.bind(method) and uncurryThis(method). I used uncurryThis because the comment that's with it is about performance.
Or are you talking about the property access (Array.isArray vs ArrayIsArray)? Again I don't know, but I hope that optimized code doesn't suffer from that.
| if (!Reflect.getOwnPropertyDescriptor(dest, key)) { |
|---|
| const desc = Reflect.getOwnPropertyDescriptor(src, key); |
| if (typeof desc.value === 'function') { |
| desc.value = uncurryThis(desc.value); |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was talking about this, as this affect all prototype methods, not just the Function ones.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is already what was done manually in all the files I changed (either with call.bind or uncurryThis). This is centralizing the uncurrying to this file. If we want to use the methods safely, we have to call them without going through the prototype.
targos added a commit that referenced this pull request
This changes the primordials to expose built-in prototypes with their methods already uncurried. The uncurryThis function is therefore moved to the primordials. All uses of uncurryThis on built-ins are changed to import the relevant prototypes from primordials. All uses of Function.call.bind are also changed to use primordials.
PR-URL: #27096 Reviewed-By: Ruben Bridgewater ruben@bridgewater.de Reviewed-By: James M Snell jasnell@gmail.com Reviewed-By: Joyee Cheung joyeec9h3@gmail.com
This was referenced
Apr 23, 2019
This was referenced
Apr 23, 2019
Labels
PRs that have at least one approval, no pending requests for changes, and a CI started.
Issues and PRs related to general changes in the lib or src directory.