Nuking misleading properties in `Object.getOwnPropertyDescriptor`

Tom Van Cutsem at
Tue Mar 12 08:45:38 PDT 2013

Hi Nathan,

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

> Given that `defineProperty` uses properties on the prototype of the
> descriptor[1] and `getOwnPropertyDescriptor` returns an object which
> inherits from `Object.prototype`, the following use-case is volatile:
>     function copy(from, to) {
>         for (let name of Object.getOwnPropertyNames(from))
>             Object.defineProperty(to, name,
>                 Object.getOwnPropertyDescriptor(from, name));
>     }
> If a third party script happens to add `get`, `set`, or `value` to
> `Object.prototype` the `copy` function breaks.

To my mind, the blame for the breakage lies with `Object.prototype` being
mutated by the third-party script, not with property descriptors inheriting
from Object.prototype. Thus, a fix for the breakage should address that
directly, rather than tweaking the design of property descriptors, IMHO.

(2) Use the introduction of `Reflect.defineProperty` as an opportunity to
> "fix" this function to only inspect own properties on the property
> descriptor so that the descriptor's prototype doesn't matter. This is
> similar to the addition of `Number.isNaN` to fix the broken `isNaN`.

Apart from the fact that Reflect.defineProperty returns a boolean success
value rather than throwing or returning normally, I would not be in favor
of changing the semantics of the Reflect.* functions much from the Object.*
functions. Your suggestion is reasonable, but I wonder if the inconsistent
behavior it introduces isn't going to cause more confusion than the problem
it intends to fix in the first place.

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

More information about the es-discuss mailing list