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

[kevinlacotaco]

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]

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

[kevinlacotaco]

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]

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.

[kevinlacotaco]

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]

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?

[dalgard]

This is still relevant, though.