July 26, 2012 TC39 Meeting Notes
brendan at mozilla.org
Sat Jul 28 14:58:10 PDT 2012
Tom Van Cutsem wrote:
> Thanks to Rick for his notes. The discussion on proxy-related issues
> went fast and touched upon a variety of issues. I complemented Rick's
> notes on the proxy discussion with some notes on the proxies wiki
> page, see:
Thanks for the wiki update, really useful in my opinion. One note on
your first bullet there:
"* If __proto__ is specified in Annex B, consider adding a
|getPrototypeOf| trap. This would simplify membranes. Writable __proto__
already destroys the invariant that the [[Prototype]] link is stable.
Engines already need to accomodate."
We agreed to require __proto__, so put it in the main spec, at the May
My memory and the meeting notes show that we agreed there to make
__proto__ a magic data property. Those favoring accessor were not
voluble, but we talked about poisoning the setter reflection if
__proto__ ended up spec'ed as an accessor.
> > getPrototypeOf trap result should be consistent wth target
> object's proto
> > MM: if the proto can be changed, the proxy should…?
> > TVC: spec interceptable [[Prototype]]
> > [[Prototype]] is currently an internal prop
> > Would need to become internal accessor prop or split into
> > / [[SetProto]]
> > [[GetProto]] / [[SetProto]] would trigger traps for proxies
> > AWB/BE: This is good
> > YK: Do we want an analogous setPrototypeOf trap?
> > TVC: Yes
> This is inconsistant with below...
> To clarify, I think we'd only need setPrototypeOf if __proto__ would
> end up being specified as an accessor (to trap
> Object.getOwnPD(Object.prototype,'__proto__').set.call(proxy) )
That's another reason not to reflect __proto__ as an accessor with a
callable setter. Either magic data, or poisoned set (and get?) accessor.
We should strive to agree on this, since SpiderMonkey went against the
decision from May, joining JSC in reflecting __proto__ as an accessor.
More information about the es-discuss