Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Standards compliant approach to allowing _.extend to copy ES5 Getters/Setters #986

wants to merge 2 commits into


None yet
4 participants

Looked through the approaches in the past and saw they were not standards compliant.

Uses Object.defineProperty() and Object.getOwnPropertyDescriptor() which are at least partially supported back to IE8.


michaelficarra commented Feb 27, 2013

Partial support on IE8 is deceptive. It supports them for DOM nodes only, which is basically useless.

Is there a list of supported browsers anywhere I should be looking at?

I could always put a check in to see if those methods are supported and then use that otherwise use the old approach.


michaelficarra commented Feb 27, 2013

This would also introduce an inconsistency in the behaviour of _.extend in different browsers, which is exactly the opposite of underscore's goal of implementing a functional library that can be used in a browser-agnostic way.

The checks would add an inconsistency?

What browsers are supported?

It delegates to built-in functions, if present, so modern browsers will use the native implementations of forEach, map, reduce, filter, every, some and indexOf.

I don't really see how this is any different then delegating to the built in functions that underscore is already using.

I have pushed a version with checks.


michaelficarra commented Mar 1, 2013

I think I know where the disconnect is. You probably think getters/setters either exist or don't. In some JS implementations, getters/setters exist, but there's no support for defining/describing them. So when encountering an object with getters/setters in one of these interpreters, you will have observable differences from the behaviour of the same object in an engine that supports defining/describing these properties. Does that make sense?

@jashkenas jashkenas closed this Jul 6, 2013

dalgard commented Nov 25, 2013

This is still relevant, though.

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