ecmascript 6 features found in Chrome 38

Question

We have an Array with a number of properties on each page. Sometimes it has a "values" property. We examine this with myArrayObject['values'] and expect either a string or undefined. After updating to Chrome 38 myArrayObject['values'] returns function values() { [native code] }

After some digging this seems to be related to a V8 ticket to implement @@unscopables for the 6th Edition of ecmascript. These changes were committed two months ago. Soon after one dev tried to roll them back with the note that they were "web-breaking".

So the question is, is Array.values() an undocumented feature, early adoption an ecmascript-6 draft, a bug, or something else? Will this get rolled back? What other upcoming changes should I be aware of?

Small example in Chrome 38.0.2125.101 (on Win7 64):

var test=new Array();
// items pushed and popped
...
// test['values'] may have been set at some point
test['values']; //returns a function pointer: function values() { [native code] }.
                // yesterday this returned undefined

---

edit: From Bergi's answer this looks like a ES6 feature.

Will there be more ES6 features coming out in background patches months before the spec is released? Is there anything I can do to protect our platform? Is there some way to request ES5 compatibility mode?

Answer 1

Yes, Array.prototype.values comes from the ES6 Draft. It is a method that returns you an iterator for the values of the array.

If you want to store values in your array that are not numerically indexed, you should not use an Array but a plain object (or, in ES6, a Map).

Answer 2

Correction, @@unscopables was never rolled back from V8 -- the second change you link to was merely prepared for the case of emergency, but fortunately, we didn't need it, it was never committed. So @@unscopables ships in Chrome 38, and accordingly, so does Array.prototype.values.

There is no way to turn off ES6 features, because doing so would not be very forward-looking, and code relying on it would be doomed to break in a few months or on other browsers anyway.

The ES committee usually is very careful to not "break the web". In practice that means that no actual use cases should break, i.e., things that already occur on the web. Strictly speaking, any change breaks some hypothetical code, because even completely new features will observably change the behaviour of 'eval'. If we made avoiding even that a strict criterium then the language could never evolve a iota.

Your specific example doesn't show up in the wild, as far as I can tell. As others have replied, there is no reason to use arrays in this case, []-syntax works just as well with ordinary objects. You only want arrays when your indices are integers specifically.

The only web-breaking issues that previously surfaced with the new Array.prototype.values method had to do with the 'with' construct (which you shouldn't use, ever). Then @@unscopables was introduced to work around that.

Edit: .values had to be removed from V8 again, because of a bug in Microsoft's OWA 2013. But consider this a temporary measure. Microsoft is aware of the problem, and .values will return as soon as possible.

Answer 3

Google Chrome 38.0.2125.111 doesn't implement anymore Array.prototype.values.

This small test

var myArray = new Array();
alert(myArray['values']);
alert(myArray['anotherparameter']);

returns undefined for both alert.

However the method hasOwnProperty can be used to determine if the array has a property called values or not:

var myArray = new Array();
alert(myArray.hasOwnProperty('values')); // alert false
myArray['values'] = "Hello";
alert(myArray.hasOwnProperty('values')); // alert true

this works for browsers implementing Array.prototype.values like Opera 25.0.1614.63