Skip to content
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

lib: reduce util.is*() usage #647

Closed
wants to merge 1 commit into from
Closed

lib: reduce util.is*() usage #647

wants to merge 1 commit into from

Conversation

cjihrig
Copy link
Contributor

@cjihrig cjihrig commented Jan 29, 2015

Many of the util.is*() methods used to check data types simply compare against a single value or the result of typeof. This commit replaces calls to these methods with equivalent checks. This commit does not touch calls to the more complex methods (isRegExp(), isDate(), etc.), which are infrequently used anyway.

Closes #607

@brendanashworth
Copy link
Contributor

This will conflict with the changes in #601 and #605, by the way.

@Fishrock123
Copy link
Contributor

I think we should document which conventions we will be using first.

@cjihrig
Copy link
Contributor Author

cjihrig commented Jan 31, 2015

Are docs the only thing holding this up? I think @chrisdickinson was going to write something up.

@chrisdickinson
Copy link
Contributor

I'll have a PR this coming week. I would not consider that a blocker for landing this.

@@ -27,7 +27,8 @@ function ClientRequest(options, cb) {
var defaultAgent = options._defaultAgent || Agent.globalAgent;
if (agent === false) {
agent = new defaultAgent.constructor();
} else if (util.isNullOrUndefined(agent) && !options.createConnection) {
} else if ((agent === null || agent === undefined) &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be shortened to agent == null.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I'll update these. I was trying to avoid using ==.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, I'll leave it to your good judgment. Doing the explicit checks is a little more efficient than == because they don't generate an IC.

@bnoordhuis
Copy link
Member

Do people have opinions on what is better, Array.isArray(x) or x instanceof Array? I ask because of the following:

> var x = []; x.__proto__ = {};
{}
> Array.isArray(x)
true
> x instanceof Array
false

With Array.isArray(), you don't know if Array prototype methods are available on the instance.

Second question: should String objects be considered strings? Right now, only primitive strings are accepted. new String('foo') is either rejected or (in the binding layer) asserts.

@rvagg
Copy link
Member

rvagg commented Jan 31, 2015

@chrisdickinson will your style-guide cover the specifics of when to use what type of type checking? There was a suggestion in the TC meeting to bring @micnic in to help with that effort since he raised the concern originally in #607. So, if it's not straight-forward and you'd like input, then you could try and rope him in and use this PR as a basis for coming up with that specific list of rules for a style-guide.

@vkurchatkin
Copy link
Contributor

@bnoordhuis there is an opposite example: vm.runInNewContext('[]') instanceof Array. Returns false, though it actually IS an array and has all prototype methods available.

@cjihrig
Copy link
Contributor Author

cjihrig commented Jan 31, 2015

FWIW, the current util.isArray() is just an alias to Array.isArray().

Many of the util.is*() methods used to check data types
simply compare against a single value or the result of
typeof. This commit replaces calls to these methods with
equivalent checks. This commit does not touch calls to the
more complex methods (isRegExp(), isDate(), etc.).
@cjihrig
Copy link
Contributor Author

cjihrig commented Jan 31, 2015

@bnoordhuis I've updated the isObject() checks.

@@ -893,7 +893,7 @@ function _validateStdio(stdio, sync) {
wrapType: getHandleWrapType(handle),
handle: handle
});
} else if (util.isBuffer(stdio) || util.isString(stdio)) {
} else if ((stdio instanceof Buffer) || typeof stdio === 'string') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parens are superfluous here.

@bnoordhuis
Copy link
Member

LGTM sans a tiny style nit. Land at will if https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/142/ is happy.

cjihrig added a commit that referenced this pull request Feb 1, 2015
Many of the util.is*() methods used to check data types
simply compare against a single value or the result of
typeof. This commit replaces calls to these methods with
equivalent checks. This commit does not touch calls to the
more complex methods (isRegExp(), isDate(), etc.).

Fixes: #607
PR-URL: #647
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
@cjihrig
Copy link
Contributor Author

cjihrig commented Feb 1, 2015

Landed in 6ac8bdc

@cjihrig cjihrig closed this Feb 1, 2015
@cjihrig cjihrig deleted the util-is branch February 1, 2015 04:54
brendanashworth added a commit to brendanashworth/io.js that referenced this pull request Mar 14, 2015
This commit does various changes to cleanup and prep the 8ff6b81 for
merging, which include updating the commit to follow new codebase
guidelines. The following are the changes:

doc/api/http.markdown:
  - document options
lib/http.js:
  - no changes
lib/_http_server.js
  - changes regarding isObject (nodejs#647) and hasOwnProperty (nodejs#635)
  - take tls option rather than guessing based on options
test/simple/test-https-from-http.js:
  - moved to parallel directory, crypto test, removed copyright banner
test/parallel/test-http-server.js:
  - adjust for tls option
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants