On Mon, Jun 15, 2015 at 10:44 AM, Alex Harui <aha...@adobe.com> wrote:
> Sure, that’s for Google Closure Compiler. My point was that we could > write an emitter that emits TS instead of JS and use the TS compiler > instead of GCC. However, if TS isn’t really handling subclassing and > overrides that well, it probably isn’t a candidate. > > Why? Seems like one extra step. I am trying to think of a reason, maybe just being numb. TS compiler does not minify or optimize like GC, which is what you want right? I know I read a GIT issue about this and the TS devs said there are tools that do this already and unless that had a real reason to spend their time on it, it wouldn't happen. They did say they were thinking about adding closure compiler extern emitter to it. As far as subclassing, it handles it fine, it's properties that they don't support right now. As I said previously, they say call Java like mutator methods. So if you wrote an emitter, all properties would be converted to "setFoo(), getFoo()" but that could be a conflict as some AS code could actually contain those methods. Mike > -Alex > > On 6/15/15, 6:38 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >To add, that they also know that the JS to TS is not clean cut and their > >are some things that might not work right or take a large amount of time > >to > >get working correctly. > > > >Mike > > > >On Mon, Jun 15, 2015 at 9:36 AM, Michael Schmalle > ><teotigraphix...@gmail.com > >> wrote: > > > >> That is the debate and I think the main compiler devs are against it. > >>They > >> want to keep the compiler JavaScript standards based. > >> > >> Although, you don't see them saying it's a bad idea, just that they want > >> to keep the compiler "agnostic". I think they are meeting half way with > >> types and annotations. > >> > >> I'm thinking about contributing to this project in the future, I am > >>really > >> impressed with their framework and compiler. > >> > >> Their codegen path is not a clean plugin approach, so it is not a > >>trivial > >> task producing TypeScript as it is. > >> > >> Mike > >> > >> On Mon, Jun 15, 2015 at 9:31 AM, Alex Harui <aha...@adobe.com> wrote: > >> > >>> Is another option is to output TS instead of JS? > >>> > >>> On 6/15/15, 3:35 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >>> > >>> >> > >>> >> So Erik, are you saying that since it soon will fully support ES6, > >>>the > >>> >> FalconJX compiler should be able to emit ES6? > >>> >> > >>> > > >>> >Most certainly. The combination of ES6 and 'TypeScript typing' > >>> (ES6_TYPED) > >>> >support should make the life of FalconJX much easier. To me it seems > >>>that > >>> >there is lot's less 'transpilation' necessary to go from AS to > >>>ES6_TYPED > >>> >than is currently needed. > >>> > > >>> >Also: I do think that ES6 is already fully supported, although maybe > >>>not > >>> >at > >>> >'zarro boogs'. The main interesting thing to watch for is how far they > >>> >will > >>> >take the 'TypeScript' support. From what I've been reading (forums and > >>> >GitHub), it looks like they may go for the full monty (fingers > >>>crossed). > >>> > > >>> >EdB > >>> > > >>> > > >>> > > >>> > > >>> >-- > >>> >Ix Multimedia Software > >>> > > >>> >Jan Luykenstraat 27 > >>> >3521 VB Utrecht > >>> > > >>> >T. 06-51952295 > >>> >I. www.ixsoftware.nl > >>> > >>> > >> > >
