On 8/30/13 11:55 PM, Josh Matthews wrote:
The current DOM bindings can only fallibly unwrap object types that have
complete WebIDL prototype chains (ie. we can grab the interface ID array
from the object and compare the slot in the chain we care about with the
one we're trying to unwrap). This causes a problem for things like
WindowProxy
Why would you ever need to "unwrap" a WindowProxy? What would that even
mean?
A WindowProxy is just a JS proxy object; all it does is forward things
through to the Window and implement an indexed getter (and maybe
security checks, in theory, though in practice I think Gecko uses
separate security wrappers for that). In my opinion, there should be no
Rust-side reflection of WindowProxy. Just Window and something to
represent a navigation context.
A possibly bigger problem are things like this:
interface Foo {};
interface Bar {};
Bar implements Foo;
interface Baz {
void doSomething(Foo arg);
};
Baz implements Foo;
where you need not only a type on the native side to represent "Foo" but
you also need to convert things to that type somehow. For this case
Gecko uses QI right now. The good news is that there are precisely 0
instances of this pattern in Gecko's non-test WebIDL, so it's quite
possible that you can kick the can down the road on this for a bit...
possibly forever. Even if this case does need to be addressed, testing
whether the incoming thing implements Foo would be pretty simple: you
codegen tests that it implements one of the LHS of those implements
statements. See the sort of thing that Gecko's bindings codegen for
mozilla::dom::SVGUnitTypesBinding::_hasInstance, for example. That
handles the "does this implement?" checks, but leaves the problem of how
to represent on the Rust side unsolved. The right solution may well
just be a union type that can hold Bar or Baz.
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
