Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
mjs at apple.com
Sat Sep 26 16:57:19 PDT 2009
On Sep 26, 2009, at 4:41 PM, Oliver Hunt wrote:
> The specific problem is that host objects cannot necessarily match
> the semantics of ES5, and for that reason the interaction of host
> objects with the ES5 semantics is unclear.
I think mapping Web IDL behavior to ES5 property descriptors would
help make this interaction more clear.
> There are additional concerns -- various es5 features expose the
> underlying implementation mechanisms of the binding -- for instance
> using get or set properties on a dom binding would require
> getOwnPropertyDescriptor to expose that implementation detail.
getOwnPropertyDescriptor risks leaking implementation details (or at
least implementation differences) in any case. The options for Web IDL
1) Leave the results of getOwnPropertyDescriptor completely
implementation-defined, so different implementations may return
2) Require getOwnPropertyDescriptor to return specific results that
expose host object properties as something other than getters or
3) Require getOwnPropertyDescriptor to return specific results that
expose host object properties as getters/setters.
I reluctantly conclude that #3 is best. #1 leaves behavior
unspecified, this needlessly creates the potential for interop
problems. #2 conflicts with the way some implementations implement
their DOM bindings (e.g. Gecko), meaning extra work for them, and is
outright unimplementable in pure ECMAScript. #3 conflicts with the way
some implementations implement their DOM bindings (e.g. WebKit) and
would mean extra work for them.
#3 seems like it has the weakest disadvantages, even though it means
extra work for us.
However, if we want to allow implementation variance (i.e. policy #1),
we could still use ES5 getters and setters as the formal model, but
say that host objects implementations may override [[GetOwnProperty]]
to give implementation-defined results for host attributes. This would
change Web IDL from saying that host object implementations MUST
override internal methods to saying they MAY.
More information about the es-discuss