Nuking misleading properties in `Object.getOwnPropertyDescriptor`

Tom Van Cutsem tomvc.be at gmail.com
Tue Mar 12 08:45:38 PDT 2013


Hi Nathan,

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

> 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.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130312/b38fa976/attachment.html>


More information about the es-discuss mailing list