| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
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').
Sorry, something went wrong.
There was a problem hiding this comment.
That's how I understand it too.
Sorry, something went wrong.
There was a problem hiding this comment.
Done!
Sorry, something went wrong.
|
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? |
Sorry, something went wrong.
|
AFAIK changing error message(s) still makes it a semver-major change. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@seishun The default options is used because, the functions which call getOptions handle the "options passed which are actually functions" case. |
Sorry, something went wrong.
There was a problem hiding this comment.
Can we please place this in an if (). no sense abusing JS's logical operators to run code.
Sorry, something went wrong.
There was a problem hiding this comment.
Ya sure... I changed it to an if block.
Sorry, something went wrong.
There was a problem hiding this comment.
Why not keep the other tests and adapt the string?
Sorry, something went wrong.
There was a problem hiding this comment.
@silverwind Now, I just changed the strings and allowed only null.
Sorry, something went wrong.
|
LGTM with question. |
Sorry, something went wrong.
|
Bump! |
Sorry, something went wrong.
There was a problem hiding this comment.
Just want to double check that using == null is intentional?
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, @trevnorris. It is intentional.
Sorry, something went wrong.
There was a problem hiding this comment.
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
Sorry, something went wrong.
There was a problem hiding this comment.
(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.
Sorry, something went wrong.
There was a problem hiding this comment.
@ronkorving Fair Enough. Changed it.
Sorry, something went wrong.
|
One question, otherwise LGTM |
Sorry, something went wrong.
|
Okay, added a commit to fix #7655 as well. PTAL. |
Sorry, something went wrong.
There was a problem hiding this comment.
We should probably only do this where we need to modify it, otherwise there will be a hit to each call
Sorry, something went wrong.
There was a problem hiding this comment.
@Fishrock123 You mean if we don't actually modify options, we don't want to create this copy?
Sorry, something went wrong.
There was a problem hiding this comment.
Correct
Sorry, something went wrong.
There was a problem hiding this comment.
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?
Sorry, something went wrong.
There was a problem hiding this comment.
@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)
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
To think of it, it just copies things to defaultOptions. That object is constructed already in memory. Would this still be a problem?
Sorry, something went wrong.
|
LGTM |
Sorry, something went wrong.
|
@micnic how do you think it could be done in a non semver major way? |
Sorry, something went wrong.
|
@thealphanerd something like options = util._extend({}, options); as the first expression in the affected methods would do the job, I don't think it is a semver major because it's an expected behavior and everywhere in the core modules except for some fs methods the external objects are not modified. In any case the impact of this change would be minimal, I could discover this only by using Object.freeze(), most of the users are using inline defined objects without reusing or freezing them. |
Sorry, something went wrong.
|
Rebased. CI Run: https://ci.nodejs.org/job/node-test-pull-request/3380/ |
Sorry, something went wrong.
|
@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… |
Sorry, something went wrong.
|
/cc @phated On Sat, Aug 27, 2016, 11:02 AM Anna Henningsen notifications@github.com
|
Sorry, something went wrong.
|
Squashed and Rebased. |
Sorry, something went wrong.
Sorry, something went wrong.
|
CI looks good other than a known flaky failure. @thefourtheye, do you want to go ahead and get this landed? |
Sorry, something went wrong.
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.
Sorry, something went wrong.
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 <benjamingr@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Nicu Micleușanu <micnic90@gmail.com> Reviewed-By: Yorkie Liu <yorkiefixer@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
Is this only semver-major due to the changed error messages? If so, would it make sense to pull this into v7.0.0? To me the diff looks like it could likely cause conflicts when backporting to v7 otherwise… |
Sorry, something went wrong.
|
@addaleax The encoding assertion happens for all the functions now. That also would qualify as a major change I believe. |
Sorry, something went wrong.
|
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? |
Sorry, something went wrong.
|
yeah, prefer major. If you want it in v7 we should discuss this now |
Sorry, something went wrong.
|
I'm ok with pulling this into v7. @nodejs/ctc ... thoughts? |
Sorry, something went wrong.
|
Seems okay to me, yes. 👍 |
Sorry, something went wrong.
|
If there are no objections from @nodejs/ctc by Monday, I'll pull this in to v7.x-staging |
Sorry, something went wrong.
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 <benjamingr@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Nicu Micleușanu <micnic90@gmail.com> Reviewed-By: Yorkie Liu <yorkiefixer@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <benjamingr@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Nicu Micleușanu <micnic90@gmail.com> Reviewed-By: Yorkie Liu <yorkiefixer@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <benjamingr@gmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Nicu Micleușanu <micnic90@gmail.com> Reviewed-By: Yorkie Liu <yorkiefixer@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
| Back | FazBrowse Home | New Git URL |
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.