OK, I have pushed changes so that all mucking with the output is controlled by compiler flags. They are:
-remove-circulars -js-output-optimization=<optimization strategy> None of these options are on by default, so you may start seeing errors when compiling your app and need to add one or more of these options because what -remove-circulars did was on by default before this commit. The -remove-circulars options scans the goog.require lines in every .JS file in the app and starting with the main app, chases down the tree of class dependencies and removes goog.requires that have already been seen in order to prevent Google Closure Compiler from seeing a circular dependency. I have implemented two optimization strategies: -js-output-optimization=skipAsCoercions does not generate Language.as calls where it sees the "as" keyword used in casting/coercion. You can also control Language.as calls with special asdoc tags "@flexjsignorecoercion <fully-qualified class name>" -js-output-optimization=skipFunctionCoercions does not generate Language.as calls for uses of "function" coercions if it finds the no try-catch blocks in the function surrounding the code. Interestingly, this means that we can implement other strategies as well and let folks choose. I pondered whether to implement a strategy called "SkipAsAfterIs" that would skip the Language.as call if it found the "as" was immediately preceded by an "is" check. Or another strategy called "skipAsUnlessAssignment" that would skip the Language.as call if it found the "as" was used outside an assignment expression such as (foo as Bar).someProperty. I have updated the examples to use some of these flags since they would otherwise report circular dependency errors. I'm now going start on the folder renaming and other refactoring to get a more Maven-friendly folder structure in the flex-asjs repo. -Alex On 1/8/16, 11:52 PM, "Alex Harui" <aha...@adobe.com> wrote: > > >On 1/8/16, 11:39 PM, "jude" <flexcapaci...@gmail.com> wrote: > >>I would expect it to keep the same behavior and take a performance hit in >>exchange. You can always add the option to "speed up" the JS version by >>removing any of the casting methods. Have you tested the difference with >>it >>and without it in JS? > >I haven't, but it is not always a cheap function call. > >> >> >>*"...but the Google Closure Compiler implies that you should have >>goog.require statements for all dependencies in an output file, and then >>complains about circular dependencies if you do."* >>It seems like the problem is with the Google Closure Compiler. That >>sounds >>broken to me. > >Google is insisting that you should use interfaces and not have classes >depend on other classes. So they will say it isn't broken. I've just >about finished putting all of these options into compiler options. None >of them will be on by default so you will all get to see where Google >thinks you have circularities. > >What the defaults are when we release will depend on customer feedback. > >-Alex >
