You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2015/06/15 10:38:55 UTC
Closure Compiler; ES6_TYPED!
Hi,
While I'm sorry to say that I'm still knee deep in a work project and won't
have time to contribute for some time yet, this weekend I ran across
something that might be helpful for the project:
The Closure Compiler has made large improvements over the past few
releases. One area is ECMASript 6 (JS.Next; Harmony) support. The GCC is
now able to take nearly all ES6 syntax and transpile it to ES3/ES5 before
optimizing it.
Most interesting of the new JavaScript features is native support for
'class' and 'extends'. Another is modules: 'import' and 'export'.
Another interesting development is that the GCC is getting support for
TypeScript style type annotation.
Taken together this means that the GCC is increasingly capable of parsing
JavaScript that eerily looks like Actionscript:
<code>
import Hello from './Hello';
export default class ByeBye extends Hello {
constructor () {
super();
}
sayHello(value:string):string {
return super('World') + ' again (by: ' + value + ')';
}
}
</code>
I've uploaded [1] an example 'project' - including all features described
above, with latest GCC and ant build file with the proper GCC arguments -
to my personal Apache area [1] for you viewing and playing pleasure.
Have fun!
EdB
1: http://s.apache.org/6SZ
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Closure Compiler; ES6_TYPED!
Posted by Michael Schmalle <te...@gmail.com>.
But yeah, you could name is something else like you were doing foo_set_()
and the odds are they didn't write that.
Anyway a TS emitter isn't going to happen on my watch. :)
Mike
On Mon, Jun 15, 2015 at 2:15 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> >
> > Erik, this was in regards to Alex asking about a TypeScript emitter for
> AS
> > - > TS. I said TS doesn't support property inheritance yet, so you would
> > have to rename properties to set/get when doing a TS emitter. The I said,
> > some AS dev might already have a setFoo() where they also have a set
> > foo(value:Object)
> >
>
> Ah, sorry for the noise ;-)
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: Closure Compiler; ES6_TYPED!
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>
> Erik, this was in regards to Alex asking about a TypeScript emitter for AS
> - > TS. I said TS doesn't support property inheritance yet, so you would
> have to rename properties to set/get when doing a TS emitter. The I said,
> some AS dev might already have a setFoo() where they also have a set
> foo(value:Object)
>
Ah, sorry for the noise ;-)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Closure Compiler; ES6_TYPED!
Posted by Michael Schmalle <te...@gmail.com>.
Erik, this was in regards to Alex asking about a TypeScript emitter for AS
- > TS. I said TS doesn't support property inheritance yet, so you would
have to rename properties to set/get when doing a TS emitter. The I said,
some AS dev might already have a setFoo() where they also have a set
foo(value:Object)
Mike
On Mon, Jun 15, 2015 at 2:08 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> >
> > 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.
> >
>
> I just tried this:
>
> <code>
> class Hello {
>
> constructor () {
> this.myProp_ = '';
> }
>
> get myProp() {
> return this.myProp_;
> }
>
> set myProp(value) {
> this.myProp_ = value;
> }
>
> }
> </code>
>
> Which compiles fine, the output uses 'Object.defineProperties()' to create
> the getter and setter on the prototype. I don't see 'getMyProp()' or
> something. Did I misread your statement?
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: Closure Compiler; ES6_TYPED!
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>
> 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.
>
I just tried this:
<code>
class Hello {
constructor () {
this.myProp_ = '';
}
get myProp() {
return this.myProp_;
}
set myProp(value) {
this.myProp_ = value;
}
}
</code>
Which compiles fine, the output uses 'Object.defineProperties()' to create
the getter and setter on the prototype. I don't see 'getMyProp()' or
something. Did I misread your statement?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Closure Compiler; ES6_TYPED!
Posted by Michael Schmalle <te...@gmail.com>.
On Mon, Jun 15, 2015 at 10:44 AM, Alex Harui <ah...@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" <te...@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
> ><teotigraphixllc@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 <ah...@adobe.com> wrote:
> >>
> >>> Is another option is to output TS instead of JS?
> >>>
> >>> On 6/15/15, 3:35 AM, "Erik de Bruin" <er...@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
> >>>
> >>>
> >>
>
>
Re: Closure Compiler; ES6_TYPED!
Posted by Alex Harui <ah...@adobe.com>.
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.
-Alex
On 6/15/15, 6:38 AM, "Michael Schmalle" <te...@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
><teotigraphixllc@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 <ah...@adobe.com> wrote:
>>
>>> Is another option is to output TS instead of JS?
>>>
>>> On 6/15/15, 3:35 AM, "Erik de Bruin" <er...@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
>>>
>>>
>>
Re: Closure Compiler; ES6_TYPED!
Posted by Michael Schmalle <te...@gmail.com>.
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 <teotigraphixllc@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 <ah...@adobe.com> wrote:
>
>> Is another option is to output TS instead of JS?
>>
>> On 6/15/15, 3:35 AM, "Erik de Bruin" <er...@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
>>
>>
>
Re: Closure Compiler; ES6_TYPED!
Posted by Michael Schmalle <te...@gmail.com>.
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 <ah...@adobe.com> wrote:
> Is another option is to output TS instead of JS?
>
> On 6/15/15, 3:35 AM, "Erik de Bruin" <er...@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
>
>
Re: Closure Compiler; ES6_TYPED!
Posted by Alex Harui <ah...@adobe.com>.
Is another option is to output TS instead of JS?
On 6/15/15, 3:35 AM, "Erik de Bruin" <er...@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
Re: Closure Compiler; ES6_TYPED!
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>
> 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
Re: Closure Compiler; ES6_TYPED!
Posted by Michael Schmalle <te...@gmail.com>.
Yeah, I saw this when I was studying the GCC code. Sad to say I actually
understand their parser and object model now. :)
Looking at the code, they are just about to implement a new type inference
system as well, in the EXTERNC compiler I am writing, the evaluate() method
will soon take a ITypeRegistry which is the new type inference.
I know two years ago in my ignorance, I poo pooed the compiler but now that
I actually understand the source, it really is one of the best Javascript
compilers around and whether people agree with how it does advanced
optimizations, the parser itself is rock solid and totally being maintained
and advanced.
If this whole AS > JS thing takes off, it would also be worth changing all
the JSDocEMitter stuff to use their JSDocInfoBuilder class, it is a builder
that knows the exact jsdoc language for it's compiler and would make the
code 100% more flexible.
So Erik, are you saying that since it soon will fully support ES6, the
FalconJX compiler should be able to emit ES6?
Mike
On Mon, Jun 15, 2015 at 4:38 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Hi,
>
> While I'm sorry to say that I'm still knee deep in a work project and won't
> have time to contribute for some time yet, this weekend I ran across
> something that might be helpful for the project:
>
> The Closure Compiler has made large improvements over the past few
> releases. One area is ECMASript 6 (JS.Next; Harmony) support. The GCC is
> now able to take nearly all ES6 syntax and transpile it to ES3/ES5 before
> optimizing it.
>
> Most interesting of the new JavaScript features is native support for
> 'class' and 'extends'. Another is modules: 'import' and 'export'.
>
> Another interesting development is that the GCC is getting support for
> TypeScript style type annotation.
>
> Taken together this means that the GCC is increasingly capable of parsing
> JavaScript that eerily looks like Actionscript:
>
> <code>
> import Hello from './Hello';
>
> export default class ByeBye extends Hello {
>
> constructor () {
> super();
> }
>
> sayHello(value:string):string {
> return super('World') + ' again (by: ' + value + ')';
> }
>
> }
> </code>
>
> I've uploaded [1] an example 'project' - including all features described
> above, with latest GCC and ant build file with the proper GCC arguments -
> to my personal Apache area [1] for you viewing and playing pleasure.
>
> Have fun!
>
> EdB
>
> 1: http://s.apache.org/6SZ
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>