ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

-----Original Message-----
From: Brendan Eich [mailto:brendan at mozilla.org]

But you raise a good
point: defineProperty creates an own property. Is there really a need
for getProperty as drafted? If not, I'd favor making describeProperty
return null if the named property is not "own", but in a prototype.

What are use-cases for getProperty as distinct from getOwnProperty?
---------------------------------------------------------------------

For awhile, defineProperty was called defineOwnProperty but we eventually decided all properties are initially defined as own properties so the "Own" was redundant.

Right now, the best I can come up with is that it should be a relatively efficient way to test for the existence of a possibly inherited property. However, if that was really important it would probably be better to have a built-in function that specifically performed that test without creating a descriptor. We may have discussed some more compelling use cases that I don't now recall, in which case I'm sure someone will remind me.

In generally, I favor proving just the minimal "spanning set" of functions that can be used to build more comprehensive reflection models if desired. If there isn't a stronger use case for the version that considers inherited methods I'd be happy to eliminate it.