allen at wirfs-brock.com
Fri Feb 10 08:29:27 PST 2012
On Feb 10, 2012, at 4:08 AM, Andreas Rossberg wrote:
> On 10 February 2012 12:46, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> I'm also in favor of exposing __proto__ as an accessor on the grounds that
>> it is least magical. I'm worried that the changes made here to the core
>> internal methods [[Get]], [[Put]], [[DefineOwnProperty]] and [[Delete]] will
>> give proxies a hard time to properly emulate this behavior if they would
>> want to do that. How would a proxy handler be able to access the internal
>> variable UnderscoreProtoEnabled?
> I also agree that an accessor is much cleaner (if we really want to
> spec this at all -- which will de facto make it a blessed feature
I share you concern.
However, we discussed this at the last TC39 meeting. Because of the current dominance of the smart mobile device space by browsers that support __proto__ browsers that have traditionally not implemented it in the more diverse desktop space are under growing pressure to include __proto__ support if they want to compete in the mobile space.
This is rapidly driving __proto__ towards being a de facto standard. Part of TC39's mission is to turn de facto standards into de jure standards and in the process provide a uniform definition for the edge cases where current implementation differ. That is exactly the sort of technical issue that we are now discussing.
> However, I'm not sure the proxy argument applies. Either way, it
> seems, proxies cannot "simulate" the magic of __proto__ themselves,
> because they have no control over the prototype they disclose anyway.
> It can only work for proxies if the magic accessor (whether implicit
> or explicit) transparently forwards the assignment to proxy targets.
> No trap would be involved, just like there is no trap for getting the
> prototype of a proxy.
Proxies could presumably trap the initial [[Put]]("__proto__") call and from that point do whatever they want. To change the this objects prototype (without reentering the trap) they would presumably use reflect.set which does a non-trapping invocation of the default [[Put]] internal method.
> I suppose the real question is: do we _want_ proxies to simulate this
> in full gory glory? That would be blessing this (mis)feature even
how would we prevent it?
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss