Annotate types that may be implemented / extended via a native class

[vsmenon]

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:

_interceptors - Interceptor
_interceptors - JSIndexable
_interceptors - JSMutableIndexable
_js_helper - JavaScriptIndexingBehavior
dart._internal - EfficientLength
dart._internal - FixedLengthListMixin
dart.collection - ListMixin
dart.core - Comparable
dart.core - Iterable
dart.core - List
dart.core - Map
dart.core - Pattern
dart.core - String
dart.core - bool
dart.core - double
dart.core - int
dart.core - num
dart.dom.html - AbstractWorker
dart.dom.html - ButtonInputElement
dart.dom.html - CanvasImageSource
dart.dom.html - CanvasRenderingContext
dart.dom.html - CheckboxInputElement
dart.dom.html - ChildNode
dart.dom.html - CssStyleDeclarationBase
dart.dom.html - DateInputElement
dart.dom.html - EmailInputElement
dart.dom.html - FileUploadInputElement
dart.dom.html - GlobalEventHandlers
dart.dom.html - HiddenInputElement
dart.dom.html - HistoryBase
dart.dom.html - ImageButtonInputElement
dart.dom.html - ImmutableListMixin
dart.dom.html - InputElementBase
dart.dom.html - LocalDateTimeInputElement
dart.dom.html - LocationBase
dart.dom.html - MonthInputElement
dart.dom.html - NavigatorCpu
dart.dom.html - NavigatorID
dart.dom.html - NavigatorLanguage
dart.dom.html - NavigatorOnLine
dart.dom.html - NumberInputElement
dart.dom.html - ParentNode
dart.dom.html - PasswordInputElement
dart.dom.html - RadioButtonInputElement
dart.dom.html - RangeInputElement
dart.dom.html - RangeInputElementBase
dart.dom.html - ResetButtonInputElement
dart.dom.html - SearchInputElement
dart.dom.html - SubmitButtonInputElement
dart.dom.html - TelephoneInputElement
dart.dom.html - TextInputElement
dart.dom.html - TextInputElementBase
dart.dom.html - TimeInputElement
dart.dom.html - UrlInputElement
dart.dom.html - UrlUtils
dart.dom.html - UrlUtilsReadOnly
dart.dom.html - WeekInputElement
dart.dom.html - WindowBase
dart.dom.html - WindowBase64
dart.dom.html - WindowEventHandlers
dart.dom.html - _CanvasPathMethods
dart.dom.html - _WindowTimers
dart.dom.svg - FilterPrimitiveStandardAttributes
dart.dom.svg - FitToViewBox
dart.dom.svg - Tests
dart.dom.svg - UriReference
dart.dom.svg - ZoomAndPan
dart.math - Rectangle
dart.math - _RectangleBase
dart.typed_data - ByteBuffer
dart.typed_data - ByteData
dart.typed_data - Float32List
dart.typed_data - Float64List
dart.typed_data - Int16List
dart.typed_data - Int32List
dart.typed_data - Int8List
dart.typed_data - TypedData
dart.typed_data - Uint16List
dart.typed_data - Uint32List
dart.typed_data - Uint8ClampedList
dart.typed_data - Uint8List
dart.typed_data.implementation - NativeTypedArray
dart.typed_data.implementation - NativeTypedArrayOfDouble
dart.typed_data.implementation - NativeTypedArrayOfInt

[vsmenon]

And, of course, validate them at compile time.

[jmesserly]

yup.

A lot of the HTML ones look internal to the HTML library cycle, right? So we could ignore everything under "dart.dom"

[jmesserly]

also NativeTypedArray shouldn't be user-visible type same with _interceptors, _js_helper, _internal

So the list of types this primarily affects is:

• dart.collection - ListMixin
• dart.core - Comparable
• dart.core - Iterable
• dart.core - List
• dart.core - Map
• dart.core - Pattern
• dart.core - String
• dart.core - bool
• dart.core - double
• dart.core - int
• dart.core - num
• dart.math - Rectangle
• dart.typed_data - ByteBuffer
• dart.typed_data - ByteData
• dart.typed_data - Float32List
• dart.typed_data - Float64List
• dart.typed_data - Int16List
• dart.typed_data - Int32List
• dart.typed_data - Int8List
• dart.typed_data - TypedData
• dart.typed_data - Uint16List
• dart.typed_data - Uint32List
• dart.typed_data - Uint8ClampedList
• dart.typed_data - Uint8List

Which seems to make sense.

[vsmenon]

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?

[jmesserly]

@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:

• we have a small set of interfaces we allow native types to implemented (Iterable, List, Map, Pattern type of things).
• we have lots of native types, but those can't be implemented (e.g. bool, int, double, String fit this mold, probably type data should as well if it does not already).

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

[jmesserly]

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.

[vsmenon]

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.

[dam0vm3nt]

Hello, just curious : could this feature help adding webcomponents/polymer2 support to dcc ?