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

Tom Van Cutsem tomvc.be at gmail.com
Sat Sep 13 13:55:27 PDT 2014


2014-09-13 17:49 GMT+02:00 Brendan Eich <brendan at mozilla.org>:

> It's not nice to lose .toString, though.
>
> Tom, didn't you have an idea for a fix? I can't find it but vaguely recall
> it (or dreamt it!).


No, not that I know of. As highlighted in the old thread linked to by
Claude, there is a legitimate use for considering inherited attributes:
inheriting defaults. Brandon Benvie stepped in to acknowledge he actually
used this pattern.

Of course, in the old thread we were talking about Object.{dP, gOPD} which
we can't change because of backwards-compat issues. Claude is suggesting we
can still change Reflect.{dP, gOPD} in this regard. I'm hesitant to do so
though, because I feel the root cause of the problem is the monkey-patching
of Object.prototype, rather than property descriptors being "badly
designed" just because they consider inherited attributes. Even if we would
fix this particular part of the Reflect API, code that does
`Object.prototype.get = ...` is likely to cause other bugs as well.

Speaking about that particular example: if one adds `Object.prototype.get =
function(){}`, then trying to define a data descriptor will immediately
fail noisily because the spec explicitly checks that a descriptor can't be
both a data and accessor property at the same time, so this particular
conflict is likely to be detected very soon.

Cheers,
Tom






>
>
> /be
>
>
> Claude Pache wrote:
>
>> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140913/a1a28af7/attachment.html>


More information about the es-discuss mailing list