RE: Defining a [[Set]] internal method for platform objects

From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 

> Chrome/Safari (they have the same behavior): During the set, the named setter is not invoked at all.  Instead an ordinary property is defined on the sessionStorage object, with name "getItem" and value "b".  During the get, the value of this property is, obviously, gotten.
>
> We _could_ implement the Chrome/Safari behavior here, I think.  It would, I believe, require the following changes from my suggested spec:
>
> 1)  In [[Set]] don't invoke the named setter in the non-overridebuiltins case if the property name would shadow something on the proto chain.
>
> 2)  Stop invoking the named setter at all from [[DefineOwnProperty]].
>
> This would mean that Object.defineProperty on a DOM proxy with a named setter never invokes the named setter, since it's only a [[Set]] that can invoke it.
>
> I'm not sure whether you'd consider this simpler or not.  ;)

Hmm, OK, yeah that is probably worse. We start with two behaviors, viz. overwrite the existing property or invoke the named setter logic, and then Chrome/Safari brings along a third, of creating a new own-property.

It seems a bit nicer in some ways, because we confine the exoticness to [[Set]] and leave [[DefineOwnProperty]] alone (except for indexed creators/setters). But from an author-facing perspective it is worse, I think.

For posterity, here are some things I noticed while looking in to all this:

- The ES spec seems to prefer a pattern where most exoticness is confined to [[DefineOwnProperty]] and [[Set]] is left alone (to delegate to an exotic [[DefineOwnProperty]] when appropriate). This seems conceptually reasonable.
- Indeed this is what the existing WebIDL spec does.
- However, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25025 specifically needs to distinguish the cases of Receiver === O and Receiver !== O.
- Thus we must add custom logic to [[Set]] instead of just [[DefineOwnProperty]] because only [[Set]] gets a receiver parameter.

Received on Tuesday, 10 February 2015 23:02:21 UTC