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