Nuking misleading properties in `Object.getOwnPropertyDescriptor`
Tom Van Cutsem
tomvc.be at gmail.com
Thu Mar 14 00:51:54 PDT 2013
2013/3/13 Nathan Wall <nathan.wall at live.com>
> 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
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
I'd like to hear Allen's opinion on this issue.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss