On 12/28/12 11:52 AM, Brendan Eich wrote:
Sure, but should all those DOM objects whose pre-WebIDL browser-specific bindings used magic data properties have to become proxies?
God, I hope not.
Has anyone checked whether doing so is (a) compatible; (b) performant?
It's not performant. It's very very hard to make performant, since proxies pretty much by definition defeat all the known JIT optimizations like inline caches based on inferred types and whatnot.
You can take a look at https://bugs.webkit.org/show_bug.cgi?id=104623 to see what happens when you try to make it performant, and at https://bugs.webkit.org/show_bug.cgi?id=105526 to see what happens when you try to make it correct.
It's possible to optimize this sort of thing in JITs in some cases by special-casing things and tighly coupling your JIT and your DOM implementation (see https://bugzilla.mozilla.org/show_bug.cgi?id=820846 and https://bugzilla.mozilla.org/show_bug.cgi?id=769911) but note that the ICs there only work because the properties the script really cares about are in fact on the proto as normal accessor properties in the common case.
All that said, I feel like I'm missing context in this discussion. Why do we need to change anything about how WebIDL attributes are reflected? There were good reasons for the current setup, including the fact that it's somewhat widely deployed already (e.g. implemented in Trident and Gecko) and that it allows authors to usefully interpose DOM getters/setters like they can already interpose methods.
-Boris _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
