On 5/31/15, 7:13 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>Cool, don't worry about it. I just finished up some other work and I am >back into the compiler refactoring. > >Funny thing dawned on my last night. I have dyslexia so sometimes I think >about things backwards. I was thinking about what you said about you and >Peter wanting this new project path to work out. And I was like, why does >this matter, why can't they just use the FlexJS emitter to create their >JavaScript. > >Then as I was finishing up some commits last night, the light bulb went >on. >HAHA They need the DOM! > >So, the I realized how important it is to just use the FlexJS emitter and >break it apart and configure it to death. Example, don't emit goog doc >comments, etc. Actually, I think I do want goog doc comments in the JS output we are going to use for AS that compiles against the HTML DOM, but I am told that it helps the Google Closure Compiler’s minifier when we shove all of the JS files into the final production output. But I agree not everybody will, so maybe that should be a flag instead of a whole other emitter. > >Plus, we are going to need some special metadata for these DOM type and >Library SWCs, like we did in Randori. We need to know if a class is >exportable and allow for name, package transformations. Not sure what you mean here. In Flex, SWCs that represent APIs that don’t need code linked in are specified on the external-library-path. > >There are a couple other things from porting frameworks that suck, one is >like jquery that has 4 different versions of a method, we can't use strict >argument checks with that unless we call the methods like; > >- show1(arg1) >- show2(arg1, arg2) Ah, interesting. Does TS have function overloading? How do they handle this? In AS, unless the signatures are truly incompatible, we can use optional arguments. Anyway, thanks for helping push this forward. You are having a significant positive impact on the future of Flex. -Alex
