Test enhancement against new native methods like Array.prototype.map

MDN, underscore.js, all list code that provide fallback if new native methods aren’t found: if (!Array.prototype.map).

The problem with this simple test is that if fails with its intent if Array.prototype.map = “map”.

My proposition is an enhanced text: text for feature signature, not just for feature name.

When testing for new native methods, like Array.prototype.map, maybe an extensive test should replace the simple if (!Arrray.prototype.map). Maybe include [native code] string test?


    function map() {
    [native code]


Array.prototype.map = "map";

tests true but not for behavior.

I’ve posted this idea of mine in a few places. I’ve edited https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map and raised an issue https://github.com/jashkenas/underscore/issues/1312.

I’m curious what the reactions will be. What do SPF finest think?

You should never run into this issue of a method equaling a string as browsers either implement it or they don’t, if the map method in your example has been defined as something else because the person running the website has overwritten it, that is a use case they have to deal with as you can only determine so much before a single person breaks your code that has implemented correctly and tested using the knowledge browsers give you.

As said in the GitHub issue there are no real world cases that meet a secondary check requirement therefore the current method for checking against these functions needs no change.

I agree, it’s an edge case.

However I can recognize the false promise made by the simple test. Can you? In the event Array.prototype.map has been overwritten, underscore.js will miraculously work or fail miserably. Especially when it’s not even checking the type, only the property name.

And, even more, even “use strict” will not help protect native methods.

"use strict";

try {
    // this fails
    // TypeError: Cannot assign to read only property 'undefined'
    undefined = "nothing to see here";
} catch(e) {

// this doesnt't fail

And it’s a use case the site users have to deal with, not the developer (the person running the site), and most likely underscore.js or some other library that uses native fallback, which gets included in the project, will likely be the first to get the blame. As it should, for not doing comprehensive checks.