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