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 > >
