Making operations on property descriptors more robust against Object.prototype hazards

Claude Pache claude.pache at gmail.com
Sat Sep 13 05:19:05 PDT 2014


Le 13 sept. 2014 à 11:47, Claude Pache <claude.pache at gmail.com> a écrit :

> Hi,
> 
> As noted some time ago, there is an issue with `Object.defineProperty` when it happens that someone has the facetious idea to give some value to `Object.prototype.get` [1].
> 
> While it is hardly an issue in day-to-day programming, I think that it is a good idea to make sure that specialized API (Reflect, proxy traps) are robust by design against that bug^H^H^H feature. Concretely, I propose:
> 
> (1) proxy.[[DefineOwnProperty]] — When a proxy defines the corresponding trap, it shall receive an object with no prototype as property descriptor.
> 
> (2) Reflect.getOwnPropertyDescriptor —That method shall return an object with no prototype, so that it can be readily used elsewhere, e.g. in Reflect.defineProperty.
> 
> —Claude
> 
> [1] http://esdiscuss.org/topic/object-prototype-get-bye-bye-object-defineproperty

One can also (either alternatively or in addition) correct the other end of the API: (1) in proxy.[[GetOwnProperty]], ignore non-own properties of the result of the trap, and (2) in Reflect.defineProperty, ignore non-own properties of the object descriptor. 

The core problem is that the two internal operations that convert between an internal representation of a property descriptor on the one side, and a concrete object representing a property descriptor on the other side, are not the inverse one of the other, because of the interference of Object.prototype.

—Claude


More information about the es-discuss mailing list