Inconsistent Object.keys behaviour with EXTEND_PROTOTYPES=false

[xcambar]

Note: This behaviour only appears when prototype extension is disabled.

Object.keys([]) and Object.keys(Ember.A()) return different arrays.

• Object.keys([]) returns an empty array
• Object.keys(Ember.A()) returns a non empty array.

This is due to the Ember mixins being injected in the native array.
It looks like the keys added to the array are not declared non-enumerable.

Here's a jsbin: https://output.jsbin.com/futequ

When prototype extensions are enabled, in both cases, an empty array is returned.

[stefanpenner]

this is currently expected behavior.

1. Object.defineProperty (used to marks as non-enumerable) is extremely slow compared to a property
2. Arrays can't be subclassed so in EXTEND_PROTOTYPES=false we currently must apply the custom methods to each and every array, not just a shared prototype. This and 1. result in it be prohibitively slow

Planned work to improve this situation, is #10899 but its quite a bit of work. Will eventually finish it up.

Although not ideal this isn't considered a bug. As such Im going to close this.

[xcambar]

Thanks and good luck.

FWIW and for future readers, your comment led me to a good read on the methods (and respective caveats) of (trying to) extend Array.prototype:
http://perfectionkills.com/how-ecmascript-5-still-does-not-allow-to-subclass-an-array/#dean_edwards_solution by @kangax.

tl;dr; hidden [[Class]] property (concat, etc... fail). Using __proto__ works but it's non-standard.