Add array grouping proposal #959
Conversation
|
@jridgewell could you review it? |
zloirock
force-pushed
the
array-grouping
branch
7 times, most recently
from
04457e2
to
4c1f476
Compare
| key = toPropertyKey(boundFunction(value, index, O)); | ||
| // in some IE10 builds, `hasOwnProperty` returns incorrect result on integer keys | ||
| // but since it's a `null` prototype object, we can safely use `in` | ||
| if (key in target) push.call(target[key], value); |
There was a problem hiding this comment.
Nit: I switched a List type in the current spec, but I don't know how you implement list (it may just be a normal array?) But I think this exposes set operations in an incorrect order?
There was a problem hiding this comment.
Lists are unobservable, so it's optimized for direct adding plain arrays to the null prototype object. If it's a custom array constructor or a typed array, they are created on a second loop pass and all observable operations evaluated in the correct order. The only observable difference with the current spec draft is an optimization of getting @@species constructor.
There was a problem hiding this comment.
Sure, it's possible to define setters on Array.prototype or Object.prototype and observe it, but I think that it's an acceptable limitation. This is a limitation of all polyfills of features that use List that I know. It's possible to use arrays with null prototype or objects with null prototype, but I don't think that it's worth it.
https://github.com/tc39/proposal-array-grouping