When I played with TypeScript, I loved that I could subclass CreateJS prototypes very easily. As long as something like that is possible from ActionScript (assuming I could provide a SWC or something for CreateJS or whichever library I want to use), I don't have too strong of an opinion on how the final JavaScript looks.
I'll just say that I like the clean code that the TypeScript compiler outputs. To me, it looked pretty much like what I might write manually, if I were using vanilla JavaScript. Looking at the TypeScript playground, the Inheritance example and the Modules example both look very nice. http://www.typescriptlang.org/Playground - Josh On Wed, May 27, 2015 at 12:02 PM, Michael Schmalle < teotigraphix...@gmail.com> wrote: > On Wed, May 27, 2015 at 2:50 PM, Alex Harui <aha...@adobe.com> wrote: > > > New thread: > > > > > > > > On 5/27/15, 9:52 AM, "Michael Schmalle" <teotigraphix...@gmail.com> > wrote: > > > > >Well, when I said "teach" I just meant getting into the code. Really, I > > >know the base part of the compiler and the walker/visitor framework well > > >;-), so getting FalconJX to use an HTML.swc would be exactly what I am > > >looking for to do. > > > > > >This is where you can keep doing what you are good at and I can work on > > >what I am good at(code rendering). > > > > > >Can I ask you to start another thread and outline what you see needs to > be > > >done to accomplish what is in your mind dealing with FalconJX and the > > >HTML.swc? If you can just brainstorm, then I can ask you questions to > fill > > >in the gaps that I am not seeing. > > > > > > > As I see it, FalconJX should just be able to grab some SWCs and > > cross-compile some AS based on definitions in the SWCs. Right now we > feed > > it playerglobal/airglobal and FlexJS swcs with UIBase widgets, but in > > theory, as Josh suggests we should be able to replace those SWCs with > just: > > > > jsglobal.swc: > > Object > > Number > > String > > <what else>? > > > > HTML.swc: > > Window > > Event > > UIEvent > > MouseEvent > > HTMLElement > > etc. > > > > > See for HTML lib, Roland used WebIDL parser to create it; > > https://github.com/RandoriAS/randori-libraries/tree/master/HTMLCoreLib > > The builtin.swc we made; > > https://github.com/RandoriAS/randori-tools/tree/develop/RandoriBuiltin > > Read the README, does this violate anything? > > > > > Then folks should be able to test drive FalconJX by running some AS > > through it to get any JS they normally use in their web apps, and we > > should be able to stop writing any JS at all. All files in flex-asjs > that > > are currently .JS files should be able to be written in AS and > > cross-compiled with only those two SWCs. I can tell you that it would > > probably have saved us much time if we had this already. It is painful > > doing .JS code simply in the writing of ‘this.’ and ‘prototype’. > > > > Yeah, not to mention compile time checking. :) > > > > > > > Anyway, that’s as far as I’ve thought on this subject. As you said in > > another thread this is where we’d have to prove there are no hard-coded > > dependencies in Falcon/FalconJX on playerglobal/airglobal. > > > > > See the above links and give feedback on what you think. > > > > > > OK, one more thought: there may be reverse-engineering issues about > > replacing playerglobal/airglobal, but I was hoping we might find some > > Tamarin code laying around that has what we’d start with for > jsglobal.swc. > > > > I think this is what Roland actually did, I know he found it some where(how > to build the builtin.swc Randori used). > > > Question; So the code style, you said we might use the FlexJS emitter but I > don't see how that is possible since it's not a vanilla emitter. > > It seems to me I need to know the exact code style that a vanilla > transpiler will create and I can make that emitter as another backend, what > do you think? > > @Josj you have any thoughts? I am ready to start writing it. :) > > Mike > > > > > > > -Alex > > > > > > >
