Open vsmenon opened 8 years ago
And, of course, validate them at compile time.
yup.
A lot of the HTML ones look internal to the HTML library cycle, right? So we could ignore everything under "dart.dom"
also NativeTypedArray shouldn't be user-visible type same with _interceptors, _js_helper, _internal
So the list of types this primarily affects is:
Which seems to make sense.
The dart.dom
types are exposed public, so we'd need to handle them similarly. Probably makes sense to have a uniform annotation / mechanism.
E.g., '@NativelyImplementable'? Better name ideas?
@vsmenon -- I thought we weren't going to support user-defined implementations of DOM types?
There's a difference between something that can be implemented by a pure Dart type, vs something that's a native type we expose to Dart.
What I had imagined is:
It probably will work, I suppose, for dart:html types, because the extension method mechanism is very powerful. But it makes me nervous for that reason, because it's a very big hammer... I'll need to think about it more. I worry we'll end up in the same sort of constrained, suboptimal design space that trapped dart2js/dart:html
just to be clear with an example, I'm concerned about:
class MockElement implements Element {
// pretend to be an HTML element!
}
To pick one obvious problem, JavaScript code and the DOM will not understand that type.
Yeah, that's a very good point. A potential problem here is:
document.body.append(new MockElement());
So, perhaps MayBeNative
and MustBeNative
or something like that is an important distinction.
Hello, just curious : could this feature help adding webcomponents
/polymer2
support to dcc ?
To generate types, we need to know if they are ever implemented via a native class. Our current solution isn't modular / scalable.
These are non-native types discovered to be extended/implemented native. We should annotate them: