ES3.1 Object static methods rationale document

Allen Wirfs-Brock Allen.Wirfs-Brock at
Wed Jul 16 13:16:59 PDT 2008

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

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.

More information about the Es4-discuss mailing list