Alex,
I didn't mean change anything you need for your work on FlexJS, I just
meant configuration, which means compiler flags. Another example would be a
flag for including the goog depends and FlexJS footer etc.
I am hoping going down this road I will learn more about JS and be able to
see how we can extend this one emitter to allow for different dependency
loading libraries as we discussed previously.
I did start a separate emitter but realized with the amount of time I had,
starting from "scratch" doesn't make sense. The things in the "jx" package
are shared and what I plan on configuring if they need it.
IMHO, the goog emitter needs to be combined and probably removed. Unless
there is really something that uses that emitter by itself?
So what I am saying is the goog emitter started the real JS emitter that
will be the foundation emitter. Now we need to abstract the really JS
emitter from the goog parts and have a goog configuration flag for example.
I know that I changed a huge amount of code last night and all the tests
pass, so other than some session model sharing, it's already pretty
decoupled. Could maybe alow for js optimizations down the road if it came
to it.
> Ah, interesting. Does TS have function overloading?
It seems to have type overloading but in the output js, obviously it
doesn't matter.
BTW another nice thing is, the way FlexJS emitts js right now it's pretty
close to TS except the closures on classes.
var Greeter = (function () {
function Greeter(message) {
this.greeting = message;
}
Greeter.prototype.greet = function () {
return "Hello, " + this.greeting;
};
return Greeter;
})();
So, my comment about multiple typed methods are type overloading which AS
doesn't have, so what do you make the parameters type? That is the problem
and why Roland had different numbered versions.
The [JavaScript(export="false", name="show")] allowed the compiler to
resolve those ambiguous methods during the emitter run so they all boiled
down to 'show()' not show2().
Question: So with the above information, you have JQuery, how do you
package it in a SWC? You have to know what the actual output is going to be
in JS.
I haven't got that far to see how the d.ts files handle this conversion.
> external-library-path
Yeah I see your point but there was some usecases where in dev code you
didn't want to export the class, you just wanted it as api, so you cannot
use this option, it's not a library, it's in an actual source path.
One other thing Mike did was have export type in Metadata which allowed
class so be exported as json and not a class, saved on memory and
performance.
All this stuff, we will cross that bridge when we get to it.
Question: the builtin.swc doesn't have say Object.create(), how are be
going to bridge the gap of what ActionScript expects for native things and
what JS adds?
Mike
On Sun, May 31, 2015 at 10:30 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 5/31/15, 7:13 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>
> >Cool, don't worry about it. I just finished up some other work and I am
> >back into the compiler refactoring.
> >
> >Funny thing dawned on my last night. I have dyslexia so sometimes I think
> >about things backwards. I was thinking about what you said about you and
> >Peter wanting this new project path to work out. And I was like, why does
> >this matter, why can't they just use the FlexJS emitter to create their
> >JavaScript.
> >
> >Then as I was finishing up some commits last night, the light bulb went
> >on.
> >HAHA They need the DOM!
> >
> >So, the I realized how important it is to just use the FlexJS emitter and
> >break it apart and configure it to death. Example, don't emit goog doc
> >comments, etc.
>
> Actually, I think I do want goog doc comments in the JS output we are
> going to use for AS that compiles against the HTML DOM, but I am told that
> it helps the Google Closure Compiler’s minifier when we shove all of the
> JS files into the final production output. But I agree not everybody
> will, so maybe that should be a flag instead of a whole other emitter.
>
> >
> >Plus, we are going to need some special metadata for these DOM type and
> >Library SWCs, like we did in Randori. We need to know if a class is
> >exportable and allow for name, package transformations.
>
> Not sure what you mean here. In Flex, SWCs that represent APIs that don’t
> need code linked in are specified on the external-library-path.
>
> >
> >There are a couple other things from porting frameworks that suck, one is
> >like jquery that has 4 different versions of a method, we can't use strict
> >argument checks with that unless we call the methods like;
> >
> >- show1(arg1)
> >- show2(arg1, arg2)
>
> Ah, interesting. Does TS have function overloading? How do they handle
> this? In AS, unless the signatures are truly incompatible, we can use
> optional arguments.
>
> Anyway, thanks for helping push this forward. You are having a
> significant positive impact on the future of Flex.
>
> -Alex
>
>
