Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.2k
fs: refactor "options" processing as a function#7165
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
thefourtheye commented Jun 5, 2016
lib/fs.js Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW v8 still does not (IIRC) optimize storing typeof foo in a variable. It's faster to just inline the typeof without using a variable (e.g. typeof actualType === 'function').
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's how I understand it too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
benjamingr commented Jun 5, 2016
Generally +1 and LGTM, left a nit. I think this can safely be a minor - this should only break code that parses error messages - right? |
mscdex commented Jun 5, 2016
AFAIK changing error message(s) still makes it a semver-major change. |
seishun commented Jun 6, 2016
While we're at it, either the error should say "object that isn't a function", or functions should be accepted as option bags too. |
thefourtheye commented Jun 6, 2016
@seishun The default options is used because, the functions which call |
lib/fs.js Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we please place this in an if (). no sense abusing JS's logical operators to run code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya sure... I changed it to an if block.
211453d to 8de37d0CompareThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not keep the other tests and adapt the string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@silverwind Now, I just changed the strings and allowed only null.
silverwind commented Jun 15, 2016
LGTM with question. |
ffd1fb8 to 706316cComparethefourtheye commented Jun 30, 2016
Bump! |
lib/fs.js Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just want to double check that using == null is intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, @trevnorris. It is intentional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes people pass null and sometimes undefined. That is why I wrote it like this. Eg: https://github.com/isaacs/node-graceful-fs/blob/master/graceful-fs.js#L89
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(a bit late, sorry)
My only beef with this is that next time a developer sees this, they may become eager to "fix" this, causing either a bug or a new discussion about this pattern. My preference is to just be explicit and check for null and undefined explicitly with ===. Just my 2 cents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ronkorving Fair Enough. Changed it.
trevnorris commented Jun 30, 2016
One question, otherwise LGTM |
706316c to 59ceb95Comparethefourtheye commented Jul 12, 2016
Okay, added a commit to fix #7655 as well. PTAL. |
lib/fs.js Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably only do this where we need to modify it, otherwise there will be a hit to each call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fishrock123 You mean if we don't actually modify options, we don't want to create this copy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, that's what I am afraid of. Then the actual logic of options processing will not at the same place. Perhaps we can have a second parameter in the function which can be used to flag if a copy has to be made. What do you think?
thefourtheyeJul 13, 2016 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fishrock123 I changed it to util._extend from Object.assign. Hope the hit will not be that much now, at least as per #7655 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does util._extend solve this problem? By the way, Object.assign should've become quite a bit faster since V8 5.1 (see http://v8project.blogspot.jp/2016/04/v8-release-51.html). Now I do believe someone was adding a benchmark to compare the two, so I'm not making the assertion that util._extends should be avoided (yet). But a copy is a copy, and is probably more than we need in quite a few cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To think of it, it just copies things to defaultOptions. That object is constructed already in memory. Would this still be a problem?
micnic commented Jul 13, 2016
LGTM |
MylesBorins commented Jul 13, 2016
@micnic how do you think it could be done in a non semver major way? |
micnic commented Jul 15, 2016
@thealphanerd something like |
8608551 to 2c279edComparethefourtheye commented Jul 21, 2016
Rebased. CI Run: https://ci.nodejs.org/job/node-test-pull-request/3380/ |
5c0feb3 to 845eeafCompareaddaleax commented Aug 27, 2016
@thealphanerd started a comparison CITGM run with v6.3.1 yesterday with the same vinyl-fs failures: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/371/ (from #8253 (comment)). That shows the same failures, so the failures here are likely unrelated… |
MylesBorins commented Aug 27, 2016
/cc @phated On Sat, Aug 27, 2016, 11:02 AM Anna Henningsen [email protected]
|
f502293 to 1b13514Comparethefourtheye commented Sep 2, 2016
Squashed and Rebased. |
thefourtheye commented Sep 28, 2016
jasnell commented Sep 30, 2016
CI looks good other than a known flaky failure. @thefourtheye, do you want to go ahead and get this landed? |
As it is, the "options" processing is repeated in all the functions which need it. That introduces checks which are inconsistent with other functions and produces slightly different error messages. This patch moves the basic "options" validation and processing to a seperate function.
1b13514 to 4693ee5Comparethefourtheye commented Oct 5, 2016
As it is, the "options" processing is repeated in all the functions which need it. That introduces checks which are inconsistent with other functions and produces slightly different error messages. This patch moves the basic "options" validation and processing to a seperate function. PR-URL: #7165 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Nicu Micleușanu <[email protected]> Reviewed-By: Yorkie Liu <[email protected]> Reviewed-By: James M Snell <[email protected]>
addaleax commented Oct 5, 2016
Is this only |
thefourtheye commented Oct 5, 2016
@addaleax The |
addaleax commented Oct 5, 2016
Okay then, that’s a bit more than just changed messages. I’m not sure, but maybe it’s still worth to ping @nodejs/ctc and see if anybody feels strongly about it? |
Fishrock123 commented Oct 5, 2016
yeah, prefer major. If you want it in v7 we should discuss this now |
jasnell commented Oct 6, 2016
I'm ok with pulling this into v7. @nodejs/ctc ... thoughts? |
addaleax commented Oct 6, 2016
Seems okay to me, yes. 👍 |
jasnell commented Oct 6, 2016
If there are no objections from @nodejs/ctc by Monday, I'll pull this in to v7.x-staging |
As it is, the "options" processing is repeated in all the functions which need it. That introduces checks which are inconsistent with other functions and produces slightly different error messages. This patch moves the basic "options" validation and processing to a seperate function. PR-URL: #7165 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Nicu Micleușanu <[email protected]> Reviewed-By: Yorkie Liu <[email protected]> Reviewed-By: James M Snell <[email protected]>
As it is, the "options" processing is repeated in all the functions which need it. That introduces checks which are inconsistent with other functions and produces slightly different error messages. This patch moves the basic "options" validation and processing to a seperate function. PR-URL: nodejs/node#7165 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Nicu Micleușanu <[email protected]> Reviewed-By: Yorkie Liu <[email protected]> Reviewed-By: James M Snell <[email protected]>
As it is, the "options" processing is repeated in all the functions which need it. That introduces checks which are inconsistent with other functions and produces slightly different error messages. This patch moves the basic "options" validation and processing to a seperate function. PR-URL: nodejs/node#7165 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Nicu Micleușanu <[email protected]> Reviewed-By: Yorkie Liu <[email protected]> Reviewed-By: James M Snell <[email protected]>
Checklist
Affected core subsystem(s)
fs
Description of change
As it is the "options" processing is repeated in all the functions
which need it. That introduces checks which are inconsistent with
similar functions and produces slightly different error messages.
This patch moves the basic "options" validation and processing to a
separate function.
cc @nodejs/fs @nodejs/collaborators
Marking this as major, as this might break some code in the wild.