WebIDL attribute reflection

Boris Zbarsky bzbarsky at mozilla.com
Sun Dec 30 08:48:16 PST 2012

On 12/29/12 10:49 PM, Boris Zbarsky wrote:
> One other note.

And one last note, promise.

The point is that SpiderMonkey is working on changing its internal model 
to more closely match the spec.  And I agree with that approach: for any 
somewhat complicated spec, using an internal model that doesn't match 
the spec model is just a recipe for pain and non-conformance.  You can 
try to fake things with enough epicycles, but like any epicycle setup as 
soon as you can make more accurate measurements you have to add more 
epicycles.  That means that things meant as "specification devices" 
become de-facto conformance requirements as specs grow hidden 
dependencies on those exact algorithms being used.

As a simple example, any time someone adds a DOM getter that calls into 
page script (assuming there is no such thing already, which I woudln't 
be on!) calls to [[GetOwnProperty]] become script-detectable if DOM 
properties are value properties (because you have to call the getter to 
fill in the descriptor), so if at that point you aren't implementing 
exactly the spec's algorithms you're detectably non-conformant.

And even if you don't call into page script, there are various getters 
that have detectable side-effects already (e.g. any of the CSSOM getters 
have side-effects on starting times of CSS transitions).  Thus if you 
use a specification device in terms of a proxy that implements 
getOwnPropertyDescriptor only, suddenly sets of offsetWidth (a readonly 
property, note) start having side-effects which they don't have right 
now, and implementations that don't have those side-effects become 
non-conformant.  Again, just as an example of how a "specification 
device" can turn into an unintended conformance requirement.

So I'm very much against using a specification device that doesn't match 
the intended implementation, which is what you seem to be proposing.  In 
my experience, that leads to implementations which don't actually match 
the spec in all sorts of edge cases.  If we're lucky, they match each 
other and all that has to happen is the spec has to be rewritten 
somehow.  But more commonly they don't match each other either, and you 
end up with interoperability problems, which means your standardization 
effort just failed...


More information about the es-discuss mailing list