tc39 / proposal-accessible-object-hasownproperty

Object.hasOwn() proposal for ECMAScript

https://tc39.es/proposal-accessible-object-hasownproperty/

MIT License

134 stars 8 forks source link

Stage 3 review #8

Closed ljharb closed 3 years ago

ljharb commented 3 years ago

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?

jamiebuilds commented 3 years ago

The note is copied directly from Object.prototype.hasOwnProperty's spec text: https://tc39.es/ecma262/#sec-object.prototype.hasownproperty

And #7 does the renaming to hasOwn and updates the links for the repo to github.com/tc39/proposal-accessible-object-hasownproperty that I was waiting to merge until transferred

ljharb commented 3 years ago

7 definitely resolves my first concern :-)

The second one tho - Object.prototype.hasOwnProperty needs that note to justify its weird exception ordering as "legacy behavior". Object.hasOwn doesn't need to have that legacy baggage.

jamiebuilds commented 3 years ago

Oh okay, I just re-read what ToPropertyKey does, I thought I was preserving the same exceptions, didn't realize it no longer threw any at all.

jamiebuilds commented 3 years ago

Should I note the order of operations is different from hasOwnProperty?

ljharb commented 3 years ago

ToPropertyKey definitely throws an exception - for example, on { toString() { throw 42; } }.

My preference is to do the ToObject first, and then sure, a note explaining the difference between that and hasOwnProperty seems great!

ljharb commented 3 years ago

Please mark my review as complete in #6.