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

Mark S. Miller erights at google.com
Sat Sep 13 16:58:01 PDT 2014


+1

Adding string-named properties to Object.prototype will create all sorts of
hazards. The only way to avoid such hazards is not to do that. We do not
need to pervert other APIs to make this fatally bad practice slightly less
fatal.

If you want to actually defend against such hazards rather than blindly
trusting all you code not to add properties to Object.prototype, do

    Object.preventExtensions(Object.prototype);

However, this will also prevent the addition of symbol-named properties,
which are still problematic but much less so.

(Or you could load SES and not have to worry about any such problems ;).)



On Sat, Sep 13, 2014 at 1:55 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

> 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.
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


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


More information about the es-discuss mailing list