WebIDL attribute reflection
bzbarsky at mozilla.com
Fri Dec 28 12:17:43 PST 2012
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
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.
More information about the es-discuss