Le 07/04/2011 20:39, Brendan Eich a écrit : > On Apr 7, 2011, at 7:49 AM, Tom Van Cutsem wrote: > >> But again, I would hope that an implementation that supports both >> Object.freeze + proxies just supports freezing proxies via the fix() trap as >> per the draft spec. I don't see the need for such an implementation to >> additionally provide an explicit mechanism like Proxy.fix. > Agreed. > > David, no need to overdesign for pathological partial-ES5 + Harmony-Proxies > implementations! That's just a non-goal. I agree too as I said in my first reply. Nevertheless, partial ES5 is not the only worry. My understanding of the fix trap design is that it is called whenever a language construct sets [[Extensible]] to false. We can expect ES implementations with proxies to implement the current language constructs which do so (Object.preventExtension|seal|freeze), I agree. But no one can predict if an Object.* method which would set [[Extensible]] to false will be added later. If it happens, people will want to monkey-patch this method in implementations that don't support it natively. (Partial ES5 was just one instanciation of this issue). Like today, no worries to monkey-patch the behavior for regular objects, but people will expect this method to have the correct behavior on proxies too. Which means having a mechanism to call the "fix" trap (with a way to distinguish call cases as suggested in https://mail.mozilla.org/pipermail/es-discuss/2011-April/013577.html ?) and to fix the proxy (TypeError||become). Without the distinction part, Object.preventExtension fits the job. With the distinction part, a Proxy.trap + Proxy.fix (or equivalent mechanisms) may be necessary.
Cheers, David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
