dart-archive / dev_compiler

DEPRECATED - Moved to main SDK
https://github.com/dart-lang/sdk/tree/master/pkg/dev_compiler
Other
133 stars 27 forks source link

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

Open vsmenon opened 8 years ago

vsmenon commented 8 years ago

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 commented 8 years ago

And, of course, validate them at compile time.

jmesserly commented 8 years ago

yup.

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

jmesserly commented 8 years ago

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.

vsmenon commented 8 years ago

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 commented 8 years ago

@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

jmesserly commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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