Justification for functionality beyond `Object.keys(obj).length`

[bakkot]

As I mentioned in plenary, I would like to better understand the motivation for supporting things other than the basic Object.keys(obj).length (and for that motivation to be documented in the readme). I don't think this proposal is ready for stage 2 until that's been done.

There's a few examples in this comment. Those examples are, in order:

• devtools
• a legitimate use to know if an object has symbol keys (though not the count)
• devtools
• devtools
• Babel's object spread helper, which would be adequately served by getOwnPropertyDescriptors
• just the second example again, minified and vendored
• devtools
• an equality method, which is actually using the full list of properties anyway
• TypeScript's object spread helper, which would be adequately served by getOwnPropertyDescriptors
• Angular's Object.defineProperties polyfill

This list of examples is not, in itself, convincing to me. Perhaps there are others, or some description of a case can we all agree is sufficiently common to warrant additional functionality?

[mhofman]

In our @endo/pass-style library we classify (deeply frozen) objects based on their shape. The goal is roughly to separate objects in 2 main categories: pass-by-copy objects which can be duplicated at will, and pass-by-reference objects for which the identity is important. I won't get into the details, but one of the requirement to be a pass-by-copy object is to be a "plain" object without expando.

This means we need to detect the following 2 cases:

• extra own properties on a TypedArray instance, which by definition can only be non-index properties
• extra own properties on an Array instance, and check that the Array is not sparse.

In both cases Object.keys(obj).length may be prohibitively expensive if the engine is not capable of optimizing the .length call for cases the arrays are very large.

However in the plain Array case getting a count of properties is not sufficient to detect the presence of expando properties if the array is sparse. We would need something like "getNonIndexStringProperties", which I believe would also work to detect TypedArray instances with expando. Since the success path is for objects without extra props, we don't really mind if the check is expensive when there are extra props.

The remaining problem is that none of these helpers allow us to detect if the array is sparse (only that a sparse array has extra props). Technically an optimized own property count (when combined with a "getNonIndexStringProperties") would allow us to detect sparse arrays, but I'm also not convinced this is sufficient motivation.

TLDR: I thought property count would help our use case, but I think it ultimately doesn't.

[gibson042]

We would need something like "getNonIndexStringProperties", which I believe would also work to detect TypedArray instances with expando.

Note that what counts as an "index" is different for Array vs. TypedArray—a property with name String(2**32 - 1) = "4294967295" would be considered an expando on the former but not the latter. Therefore anything like getNonIndexStringProperties would only be useful for both cases if there were some signal to use the Array semantics vs. the TypedArray semantics (where options for such a signal include checking the argument for a [[ViewedArrayBuffer]] internal slot, having a second parameter, calling a separate function, etc.).

But the TypedArray case can be handled by just Reflect.ownKeys(ta).length or an optimization thereof, because it must equal the length of ta if and only if ta does not have any expando properties. So @endo/pass-style does have a use case that would be improved by this proposal, it just also has a similar use case that would not be helped without something else providing an efficient predicate for sparse array detection (because if arr is known to be a non-sparse array, then its own non-expando key count is exactly Reflect.ownKeys(arr).length + 1).

[mhofman]

Note that what counts as an "index" is different for Array vs. TypedArray—a property with name String(2**32 - 1) = "4294967295" would be considered an expando on the former but not the latter.

As @bakkot mentioned, this is only a problem if a TA has a size of 2**32. If it is made clear the semantics used are that of Array (which are the most strict), I think any code consuming this can decide how to treat the "4294967295" key if it exists. Anyway that's a discussion for that proposal.

Regarding Arrays, I agree that a way to compare the key count of numeric index properties vs the total key count (or the non numeric index ones) would be a way to detect sparse arrays, which we'd very much like.