Thoughts? Seems unlikely we'll go with invariant at this point.
I'd like to see covariant generics go, but it seems we need variance annotations of some sort before that becomes realistic. (e.g. Iterable is used all over the place)
R=leafp@google.com
Review URL: https://codereview.chromium.org/1165303002
This bites us on Angular - dart:collection and angular's collection
(facade) lib smash on top of each other, silently causing issues.
We'll need a better naming convention - perhaps we should use the lib
name and require uniqueness.
Fixes#208R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1145243013
* fixes generic List. Because generic arrays have the proto of JSArray, which itself extends Array, we need to make sure we don't override members from Array.
* fixes tear offs, they were not preserving type signatures in some cases. This doesn't change how we store signatures, but perhaps something we could consider, to make this bug less likely.
* the defineExtensionMembers call was not getting emitted unless the type implemented at least one interface.
R=leafp@google.com
Review URL: https://codereview.chromium.org/1156273010
fixes#138, extension methods for Iterable/List injected as needed, regardless of how the methods started
fixes#142, extension methods and dynamic dispatch
small change that fixes#139, recognize that '.length' doesn't need an extension method
Also restores JSArray, moved the methods out of List, which is back to just being an interface.
NOTE: this removes the capability of types that mix native JS members and some Dart extension members, instead it now *hides* all JS members for these native types. We'll want to bring that feature back to support dart:html, so it's just a simplification for now. Should be easy to add that capability when we pull in dart:html for reals.
R=leafp@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1153003003
these were caught by the webstorm ES6 plugin
biggest one is strict mode doesn't like local functions except at top level, I think becasue the name is not scoped correctly (for historical reasons). Instead `let name = () => ...;` allows correct scoping for `name`.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1152783005
Reify dynamic as bottom or Object as appropriate in the generated code.
For general function types, dynamic parameters become bottom, and all other uses of dynamic become Object.
For concrete function types (the rtti attached to function objects) dynamic parameters also become Object.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1148333003
When we tear off a method, replace the obj.foo.bind(obj) pattern with dart.tearoff(obj, 'foo'), and the dart.bind(exp, 'foo') pattern with dart.tearoff(exp, 'foo'). This helper does both the bind and attaches rtti.
This CL also stops binding of static methods when they are town off, since I think this is unnecessary.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1142293002
For every class, we now generate a setSignature call which attaches properties to the constructor recording the method signatures, the static function signatures, and the names of all of the static methods. This call also attaches a getter to every static method which returns the type of the function. Methods are only decorated with runtime types when torn off. At a tear-off, the type is looked up in the constructor, and then attached to the bound function.
Top level functions and statement level functions get annotated with their type immediately after their declaration. We could consider moving all of the top level function annotations to the end of the file, but for now I've left it inline.
Closures (function expressions) get wrapped in calls to a dart.fn helper, with type information attached in one of various forms. This is currently the least attractive part of this CL. We may want to iterate on the syntax for this.
I've added some support for NSM checking to the dsend/dcall case as well.
We may wish to iterate on the syntax, and on the runtime representation of types, but this should move us forward from a functionality standpoint.
BUG=
R=jmesserly@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1138793002
Vijay Menon