Hi, @ljharb! The internet brought me here. So hi! And, sorry?

"key" means "string property"

Have I been getting this wrong? Or do you mean "key" means "string property" only in Object.keys()? (And maybe implicitly in Object.values & Object.entries, too. 😬)

Until now, my understanding was that Object.keys should have been Object.names, and that I was to think about the terms like this:

term	expectation
`has`	"returns whether the property is available"
`hasOwn`	"returns whether the property is directly available"
`hasName`	"returns whether the string property is available"
`hasOwnName`	"returns whether the string property is directly available"
`hasSymbol`	"returns whether the symbol property is available"
`hasOwnSymbol`	"returns whether the symbol property is directly available"

And that ☝️ understanding is why a proposal for Object.hasOwn would appropriately mirror Object.prototype.hasOwnProperty.

Otherwise, if "key" should mean "string", that would mean Reflect was not a helpful precedent for Object. I might then make a logical leap and expect Object.hasOwn to not work like Object.prototype.hasOwnProperty, but rather to work like Object.keys, Object.values, and Object.entries, where only string properties are used.

Mind helping me out by clarifying which terms mean what? It might help me unpack all this other mental baggage. 😅

Tracking issue for in-the-field feedback #18

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions