On __proto__ as a magical data property

Jeff Walden jwalden+es at MIT.EDU
Tue Jul 17 21:32:49 PDT 2012

On 07/17/2012 11:37 AM, Brendan Eich wrote:
> I don't know what you mean by "mutating mutation". In no case is the non-writable magic property's internal setter called. Right?

According to the draft semantics, it seems no.  Somehow I missed that semantics had made their way into any draft, and I thought the wiki (rather, discussion in meeting minutes from April sometime) was the closest thing to a spec there was.

> That's nice but it doesn't address the argument that ECMA-262, not a certain implementation, should not expose a usable setter at all (never mind wrapped and monitored).
> You'd be on stronger ground if you poisoned the reflection API so the setter could not be extracted.

I can buy the argument the setter shouldn't be exposed, more or less.  I don't think it presents intrinsic *danger* except in an ocap-y sense, but maybe I'm missing some concrete example.  If other engines can get on board with it -- and right now JSC and Opera's implementations are not, from what I understand -- I'm happy to see that tweak in SpiderMonkey, and in the spec.

> One fewer magic data property in the language still leaves magic data properties in the language, notably Array length.

One fewer magic data property is also not having to alter the fundamental [[Get]], [[Put]], and [[DefineOwnProperty]] algorithms.  I think changing those algorithms presents more risk than will having a function that will change an object's prototype if it passes the right tests.  (And certainly more risk than if the reflection API were poisoned and the function weren't even observable.)

It's true there's an element of aesthetics here, but I think this is a matter of substance as well.  I suspect we'll have to agree to disagree on that point.  (Particularly as, somewhat regrettably timing-wise, I'll be on vacation for a bit over a month starting tomorrow.)


More information about the es-discuss mailing list