Ok, I am a doer... :) Since this is all POC right now and I am up to learn some JS, I will use this as a format. I have done this JSEmitter 2 times now so the 3rd isn't going to be that hard, maybe the charm for me to.
Note, most of the expressions and statements are already done. As noted, inheritance, scope and set/get always are the pains but if I have a target output protocol like TypeScript's output, why not emulate it. Alex, I know what you are thinking... Don't. :) My gut feeling is, if I start from the ground up and have NO dependencies on anything, I will do this twice as fast. I am very good at refactoring so once I have tests working on the generated .js, we can see what could be abstracted to and from this emitter and FlexJS. I really think for my own sanity, I need to start in isolation and not get in FlexJS's way either, that is another pro for me, no commit conflicts, nothing of that nature. Thoughts Josh, Alex? Mike On Wed, May 27, 2015 at 4:40 PM, Josh Tynjala <joshtynj...@gmail.com> wrote: > 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 > > > > > > > > > > > >
