tc39 / proposal-accessible-object-hasownproperty Goto Github PK

Which use cases of objects-as-dictionaries are not better handled by using Maps?

For the symmetry purpose, can we have shorthands for all the methods defined on Object.prototype?

Rationale:
We need a counterpart to Object.keys() and Object.values(). (Object.hasOwn() being a counterpart to Reflect.ownKeys()).
I think checking has-own&enumerable is a far more common use-case than just has-own. I have seen lots of flawed code in the wild that assumes hasOwnProperty is a counterpart to Object.keys(). See: facebook/react#19921

Suggestions for a better name are welcome... propertyIsEnumerable is rather awkardly named.

Here's a polyfill:
Object.hasOwnEnumerable = Function.prototype.call.bind(Object.prototype.propertyIsEnumerable);

I perfectly understand that has is more frequent name than hasOwn for this shortcut, but we have Reflect.has which works like in operator. The rest Reflect methods work similarly to Object methods - we should avoid this inconsistency. Also, I think, the method name should point to check own properties.

Edit from @jamiebuilds:

This proposal was presented to TC39 on April 20, 2021, where it went forward to Stage 2 but the name was left in question. This issue should be used for discussing the method name further.

How about publishing the package to let folks make use of the polyfill? You already have the main field, etc. Thanks!

Using this issue as a central place to collect community feedback for in-the-field experience, positive or negative.

• spec still needs to be renamed to hasOwn
• I don't understand the note - i think it's trying to explain why ToPropertyKey throws before ToObject, but the wording implies it's for legacy compatibility, and there is no previous Object.hasOwn. In other words, if it's important to make the function truly be identical to Object.prototype.hasOwnProperty, the note needs better wording; however, it seems better to me to do the ToObject first?

As the faq why name has, "it fills in a hole in the common operations between Object, Map, and Set."

So I assume the new API should keep the semantic consistency with keys/values methods.

Map/Set all satisfy the invariant of: collection.has(key) === [...collection.keys()].includes(key)

If we also want the invariant of Object.has(o, key) === Object.keys(o).includes(key), the semantic of has() should only return true for enumerable string keys, which is different with Object.prototype.hasOwnProperty.

Stage 1

• introduced to TC39 (Presented on April 20, 2021)
• champions identified (@bnb)
• initial explainer (Explainer)

Stage 2

• committee approval (Approved on April 20, 2021)
• spec text written
• spec reviewers selected (@ljharb, @leobalter, @Felienne)

Stage 3

• committee approval
• spec editor sign off
• spec reviewer sign off
  • @ljharb
  • @leobalter
  • @Felienne
• received developer/implementer feedback
  • developers (has, lodash.has)
  • implementers

Stage 4

• committee approval
• implemented in two browsers
  • V8 (Shipped in v8 9.3) (PR: https://chromium-review.googlesource.com/c/v8/v8/+/2922117)
  • SpiderMonkey (feature-flagged, on track to ship in Firefox 92) (PR: https://hg.mozilla.org/try/rev/94515f78324e83d4fd84f4b0ab764b34aabe6d80)
  • JavaScriptCore (Bug: https://bugs.webkit.org/show_bug.cgi?id=226291)
  • engine262 (PR: engine262/engine262#163)
• significant in-the-field experience (#18)
  • SpiderMonkey has had Object.hasOwn enabled in nightly for the last month (as of July 2021) and has not received any bug reports (https://bugzilla.mozilla.org/show_bug.cgi?id=1711872#c8)
  • v8 says that they are on track to ship Object.hasOwn() in Chrome 93 in late August.
• write test262 tests (PR: tc39/test262#2995)
• merge test262 tests (PR: tc39/test262#2995)
• prepare ecma262 pr (PR: tc39/ecma262#2415)
• editor-approved ecma262 pr (Approval: tc39/ecma262#2415 (review))