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?
*"...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. On Fri, Jan 8, 2016 at 12:42 PM, Andy Dufilie <andy.dufi...@gmail.com> wrote: > I understand what you're trying to do, and I want the same things. The > greatest thing about FlexJS is that I am able to easily port my large > project (seven years of development work) with minimal change. However, > since my project relies heavily on the exact behavior of every AS language > feature, I need it to behave exactly the same after cross-compiling, or I > end up having to do painful runtime debugging of the JS output to find out > where the cross-compiler changed the behavior of my code. I'm willing to > take a performance hit if it means I can get things up and running sooner, > knowing that I can always go back and optimize the code later and/or play > with the optimization settings. I understand that if you make it easy to > put it back to the default behavior that it's not so bad, but keep in mind > that new users will expect things to "just work" and may not know about the > the compiler options or directives. > > On Fri, Jan 8, 2016 at 3:20 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > On 1/8/16, 12:11 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > > > >I should add that I strongly agree with Andy that we shouldn't change > the > > >default behavior of the existing forms of casting. That's why I made the > > >above proposal for a special function that the emitter would know to > strip > > >away. It would allow us preserve the existing casting behavior, while > > >providing a separate option that simply makes the compiler and IDEs > happy. > > >It's something additional to learn instead of discovering that what you > > >already learned is now completely wrong. I think that's safer and less > > >likely to make people angry and frustrated. > > > > I don't feel like I'm changing behavior. I think I'm trying to implement > > some compiler optimizations via hinting. For sure I will make sure there > > are enough knobs so the compiler doesn't try to optimize at all. And > when > > you set the flag to not remove circular requires, then we'll see how > folks > > feel about re-writing their code to deal with it. I think the feedback > > we've received so far is that we need to do some of this stuff because > > some folks don't want to massage their code that much. The more they > have > > to massage, the more likely they are to just port to some other > > framework/language. > > > > -Alex > > > > >
