Permalink
Show file tree
Hide file tree
11 comments
on commit
sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Fix #10466. jQuery.param() should treat object-wrapped primitives as …
…primitives.
- Loading branch information
Showing
2 changed files
with
14 additions
and
1 deletion.
There are no files selected for viewing
This file contains 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
This file contains 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
166b9d2
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.
jQuery.isPlainObject
is unnecessary here - use the fasterjQuery.type( obj ) === "object"
.Btw.:
Few lines up, there is
typeof v === "object" || jQuery.isArray(v)
that can be simplified totypeof v === "object"
.Also, if really wonted, the isPlainObject can be avoided in .param too, by replacing
a.jquery && !jQuery.isPlainObject( a )
witha.jquery && !hasOwn.call( a, "jquery" )
, but this would requirehasOwn = Object.prototype.toString
on the top - so probably not too beneficial considering that isPlainObject is called only once here.If you want I can make a pull req.
166b9d2
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.
@rkatic, I doubt this would yield any measurable performance improvement in real code, given how seldom this is called. Would you be interested in taking on a larger project for 1.8? These micro-optimizations often are more bother to change than they are worth, we need to be focusing on big gains.
166b9d2
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.
Yea, the last one is certainly an over-optimization, but I pointed it now in case something like that will be needed...
Other two, however, was more for correctness...
Do you have something in particular in mind?
I have intention to try to contribute to jQuery in next months anyway.
166b9d2
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.
My previous comment's test was backwards, strike that.
166b9d2
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.
So,
jQuery.type(foo)
will definitely work fine, but I'm not sure it's worth it? http://jsperf.com/type-vs-isplainobject166b9d2
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.
After making the change, byte counter reports:
166b9d2
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.
It's more about correctness. Consider:
Why to make this unnecessarily invalid?
Also, an more honest perf would probably be http://jsperf.com/type-vs-isplainobject/2.
166b9d2
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 is that a "more honest perf"??? Because you said so? All you've done is create more noise.
This is the BEST argument given:
Why didn't you lead with that argument instead of nitpicking some half-cocked performance micro-optimization?
166b9d2
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.
This is not the first time that we do not agree on writing perfs, even if I am simply taking in consideration different types... but at the end the ideal perf is probably something in the middle: making more probable types more frequent, but not ignoring others too.
166b9d2
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.
If you want to account for other types, do so in separate tests - it hardly makes sense to cram 3 different operations into each test.
166b9d2
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.
Maybe that would be even better, but I am not in the mood to make N tests for something like this...