Nuking misleading properties in `Object.getOwnPropertyDescriptor`

Tom Van Cutsem at
Thu Mar 14 00:51:54 PDT 2013


2013/3/13 Nathan Wall <nathan.wall at>

> However, as a matter of principle, my argument is that
> `Object.getOwnPropertyDescriptor` should, at the bare minimum, return a
> descriptor that can be known to work in `Object.defineProperty`.  If
> `Object.defineProperty` doesn't accept it, then you
> `getOwnPropertyDescriptor` didn't really give me a valid descriptor.
> I think that this behavior (1) limits the creativity of developers to
> define properties like `Object.prototype.get`, (2) is a potential stumbling
> block, (3) has no real benefit -- really, there's not anything positive
> about this behavior, and (4) forces developers who want to support
> `Object.prototype.get` to add an extra layer of cleaning before using
> `defineProperty`.

While the monkey-patching of Object.prototype ("don't do that!") is still
the culprit, I agree that it would have been better if defineProperty
looked only at "own" properties of the descriptor. I almost always think of
descriptors as "records" rather than "objects". Similarly, perhaps
Object.getOwnPropertyDescriptor should have returned descriptors whose
[[prototype]] was null.

It's true that Reflect.getOwnPropertyDescriptor and Reflect.defineProperty
give us a chance to fix this. I'm just worried that these differences will
bite developers that will assume that these methods are identical to the
Object.* versions.

I'd like to hear Allen's opinion on this issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list