Skip to content

Fixes #1739 - _.extend check for own properties #1770

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

Merged
merged 1 commit into from
Aug 4, 2014

Conversation

machineloop
Copy link
Contributor

I believe _.extend is intended to remain primitive in nature (as per issue #123), so this may be an unnecessary change.

Checks for the source object's own properties before extending a property. It includes the code from Dimik's comment resolving issue #1739. One contributed test; All tests pass.

Screenshots highlight lines of code added to underscore.js and object tests:
underscore.js:
screen shot 2014-08-01 at 2 08 24 pm
test/objects.js:
screen shot 2014-07-31 at 7 54 28 pm
Passing tests:
screen shot 2014-07-31 at 8 16 02 pm

@@ -912,11 +912,13 @@
// Extend a given object with all the properties in passed-in object(s).
_.extend = function(obj) {
if (!_.isObject(obj)) return obj;
var source, prop;
var source, prop, hasOwn = Object.prototype.hasOwnProperty;
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is already defined as hasOwnProperty.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, good point. I missed line 26 in the quick reference variables:
var hasOwnProperty = ObjProto.hasOwnProperty;

I'll push a squashed commit.

@jashkenas
Copy link
Owner

I believe _.extend is intended to remain primitive in nature

That's correct.

@jashkenas jashkenas closed this Aug 1, 2014
@jdalton
Copy link
Contributor

jdalton commented Aug 1, 2014

_.extend could align to ES6 Object.assign which iterates over own properties. I've had that aligned in my own implementation for a while now with minimal fuss.

@michaelficarra
Copy link
Collaborator

I agree with @jdalton.

@jashkenas jashkenas reopened this Aug 1, 2014
jashkenas added a commit that referenced this pull request Aug 4, 2014
Fixes #1739 - _.extend check for own properties
@jashkenas jashkenas merged commit 6993b1b into jashkenas:master Aug 4, 2014
@michaelficarra
Copy link
Collaborator

👍

@jashkenas
Copy link
Owner

In retrospect, I think it was a mistake to change this behavior. It was unnecessarily backwards-incompatible, and not obviously more useful.

If you're using it on naked objects then the behavior is identical ... but if you're using it on inherited objects then you're getting only a subset of what you were getting previously. I think that "any iterable property" is a nicer default for such a brute-force function.

So, reverting for 1.7.1...

@akre54
Copy link
Collaborator

akre54 commented Sep 2, 2014

@jashkenas 👍

@jdalton
Copy link
Contributor

jdalton commented Sep 2, 2014

Reverting this has side effects on other methods like _.clone and will miss fixes like #1755 as internally it could have used _.keys.

Devs using _.extend to flatten inheritance are better suited leveraging that inheritance through extending propertypes or using an Object.create equiv.

@akre54
Copy link
Collaborator

akre54 commented Sep 2, 2014

I agree with that. But let's push back on this breaking change til later. Let's back it out to the old behavior for now.

@jdalton
Copy link
Contributor

jdalton commented Sep 2, 2014

Yap, for 1.7.1 it makes sense to back it out as it's back compat breaking.
I just don't want to it to fall off for 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants