WebIDL attribute reflection

Boris Zbarsky 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 
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.


More information about the es-discuss mailing list