The dart runtime files are roughly split around functional boundaries. Comments at the top of each file describe the function of the library. I'm not sure that these are 100% right yet, but they're closer. We may want to iterate on the organization.
The main dart runtime file just re-exports various symbols from the sub-libraries. It has hard dependencies on the other runtime files, some of which have soft (lazy) dependencies on SDK files. The generated code now depends on dart and dartx as a imported libraries, rather than as top level symbols.
This CL also includes some new code to make type representations a bit better. This is mostly in the new types.js file, which makes all of the non-instance types (dynamic, bottom, void, function types) subtypes of a common representation type. Among other things, they now have the correct runtime type (core.Type). Some of the type code has been rationalized around this a bit, but there is more left to do here. The setSignature code in classes.js now also places the correct runtime type on nominal (instance) types. There are new tests in the runtime_tests.js file to test for this.
The static object method code that implements the Object methods has not yet been updated to dispatch on type representations. I will do that in a separate CL.
BUG=
R=jmesserly@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1182653002
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#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
Factored the load order logic into its own file, as it was easier to work with that way. We could definitely tweak the structure.
Also tried hoisting constants out to top level, but it's not quite ready yet, so splitting that work out into a separate CL.
(also fixes#152 about cleaning up lazyClass, and fixes#181 about static fields)
R=vsm@google.com
Review URL: https://codereview.chromium.org/1133593004
John Messerly