Well I got a hold of Roland and summarized, 90% of this is dead easy and the 10% killed the project.
He also stated that back when Randori was being developed, someone tried making a parser/renderer for TS to AS an eventually they had to abandon it because not all TS converts to AS correctly. I definitely don't have time to have that happen to me. So from that conversation, I guess, if someone wants to tackle it they can but it doesn't make me feel good. Without a solid answer to get this stuff to AS, it's just a waste of time in the end, I know from personal experience with Randori and I am getting that same feeling right now. Mike On Mon, Jun 1, 2015 at 6:36 AM, Michael Schmalle <teotigraphix...@gmail.com> wrote: > Heh, if we can write the tool then most of our problems are taken care of > because Microsoft has so graciously(no need for IDL I would imagine) > provided the DOM d.ts file with the Apache 2 license. > > Mike > > On Mon, Jun 1, 2015 at 6:34 AM, Michael Schmalle < > teotigraphix...@gmail.com> wrote: > >> Ok, I completely take back what I said about TS and it's parser. I have >> investigated and custom linters and other things can be made. >> >> So #4 is doable but the tool has to be written in TypeScript. >> >> See; https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API >> >> Mike >> >> On Mon, Jun 1, 2015 at 6:20 AM, Michael Schmalle < >> teotigraphix...@gmail.com> wrote: >> >>> On May 31, 2015 9:41 AM, "Michael Schmalle" <teotigraphix...@gmail.com> >>> wrote: >>> >>> > Now, I wish I had an answer of how to create a d.ts parser without >>> using >>> > 100's of dev time hours. :) >>> >>> Do you have an idea of how the input vs. output would look like? Are you >>> planning on creating a d.as file which has all the class and function >>> definitions? >>> >>> Perhaps we can start with hand coding a simple example? I can help with >>> that. >>> >>> Thanks, >>> Om >>> >>> Well I know what we had in Randori and what Roland created for SWCs, >>> that is what I am using in my prototype but, we need a spec so as to not >>> waste time. >>> >>> This really needs to be thought about and documented first. If we have >>> what a class/interface(native defs or whatever) will look like, any >>> metadata used and how I write plugins to the emitter to generate from those >>> definitions. >>> >>> So my proposal is; >>> >>> 1. Write a simple spec for the d.as definition file/s. >>> 2. Create simple test files that utilize every aspect of our spec. >>> 3. Use the handwritten test files in FalconJX emitter tests to verify >>> the cross compile. >>> 4 Think about how we can translate IDL, builtin and d.ts definitions to >>> that spec once the spec is concrete and tested within the compiler and >>> working. >>> >>> Mike >>> >>> >> >
