Yes, that makes sense. I incorrectly assumed it knew how to get that
information from SWCs too.
So, if I understand you correctly, this -external-externs argument doesn't
exist yet? It still needs to be added to externc?
- Josh
On Fri, Jun 26, 2015 at 1:29 PM, Michael Schmalle <teotigraphix...@gmail.com
> wrote:
> Ah! Yes, this is a "problem" because to generate the correct AS, we need
> the extern to be loaded in the closure compiler for my AST resolver to work
> correctly.
>
> So actually, there is no bug, other than you need to supply dependencies to
> the javascript compiler(Closure Compiler).
>
> So, what needs to be added is an -external-externs compiler arg that will
> be used to load and be parsed for the AST but NOT be emitted during the
> emit() phase.
>
> Does this make sense to you?
>
> Mike
>
>
> On Fri, Jun 26, 2015 at 4:08 PM, Josh Tynjala <joshtynj...@gmail.com>
> wrote:
>
> > 1. Yes, but let's take CreateJS out of the equation. It's not necessary
> to
> > reproduce the error.
> >
> > I created the following nativemouseevent-extern.js:
> >
> > /**
> > * @constructor
> > * @extends {MouseEvent}
> > * @param {string} type
> > * @param {MouseEventInit=} opt_eventInitDict
> > */
> > function NativeMouseEvent(type, opt_eventInitDict) {}
> >
> > When passed to externc, it produces the following AS3:
> >
> > package {
> >
> >
> >
> > /**
> > * @see [nativemouseevent-externs]
> > */
> > public class NativeMouseEvent extends MouseEvent {
> >
> > /**
> > * @param type [string]
> > * @param opt_eventInitDict [(MouseEventInit|null|undefined)]
> > * @see [nativemouseevent-externs]
> > */
> > public function NativeMouseEvent(type:String,
> > opt_eventInitDict:MouseEventInit = null) {
> > super();
> > }
> >
> > }
> > }
> >
> > Notice that super() in the constructor has no arguments. In fact, it
> should
> > have two:
> >
> > super(null, null);
> >
> > From w3c_event.js, you can see the MouseEvent constructor has two
> > arguments:
> >
> > /**
> > * @constructor
> > * @extends {UIEvent}
> > * @param {string} type
> > * @param {MouseEventInit=} opt_eventInitDict
> > */
> > function MouseEvent(type, opt_eventInitDict) {}
> >
> > If I also pass w3c_event.js to externc, to basically override what was
> > already compiled into js.swc, it will produce the correct super(null,
> null)
> > instead. So, at least as far as I can tell, if the extern is already
> > compiled to a SWC, some information about the number of constructor
> > arguments seems to get lost somehow. If it's still a raw JS extern, it
> > works fine.
> >
> > 2. I did not modify any extern files to produce this error. I will be
> > modifying a third-party extern file (not one of Google's), but this issue
> > comes up before I even get that far.
> >
> > 3. jsc is giving me a compiler error because externc is not producing
> valid
> > AS3.
> >
> > At this point, I'm not really using an IDE yet. I just wanted to get a
> > handle on the command line first.
> >
> > - Josh
> >
> >
> >
> >
> > On Fri, Jun 26, 2015 at 11:47 AM, Michael Schmalle <
> > teotigraphix...@gmail.com> wrote:
> >
> > > Josh,
> > >
> > > I am having one of those days, but I still am not quite getting what is
> > > happening with the constructor stuff.
> > >
> > > Can you spell it out one more time with maybe something I can try for
> > > myself?
> > >
> > > 1. So are you saying you are creating a .js file that you are having
> > > externc.jar parse and emit for CreatJS?
> > >
> > > 2. Can you show me what you modified in googles extern file to create
> > what
> > > you want?
> > >
> > > 3. So it's actually the jsc compiler jar that is giving you that error
> > > correct? Not an IDE.
> > >
> > > Mike
> > >
> > >
> > > On Fri, Jun 26, 2015 at 2:11 PM, Josh Tynjala <joshtynj...@gmail.com>
> > > wrote:
> > >
> > > > I actually don't need the typedef stuff right now. I was trying to
> use
> > > the
> > > > same workaround that the CreateJS TypeScript definitions use to avoid
> > > > naming conflicts between MouseEvent and createjs.MouseEvent. It
> > creates a
> > > > fake class named NativeMouseEvent that extends MouseEvent. I was
> trying
> > > to
> > > > modify the Closure externs to use the same trick. Basically, I'm not
> > > > actually instantiating this subclass. It's just a workaround to make
> a
> > > > certain property strongly typed in AS3 without creating a class name
> > > > conflict.
> > > >
> > > > If I manually go in and change the super() to super(null, null)
> before
> > I
> > > > compile the generated AS3, I'm good to go.
> > > >
> > > > - Josh
> > > >
> > > >
> > > > On Fri, Jun 26, 2015 at 10:06 AM, Michael Schmalle <
> > > > teotigraphix...@gmail.com> wrote:
> > > >
> > > > > Weird, looking at the generated source;
> > > > >
> > > > > /**
> > > > > * @param type [string]
> > > > > * @param opt_eventInitDict [(MouseEventInit|null|undefined)]
> > > > > * @see [w3c_event]
> > > > > */
> > > > > public function MouseEvent(type:String,
> > > > > opt_eventInitDict:MouseEventInit = null) {
> > > > > super(null, null);
> > > > > }
> > > > >
> > > > > It's right, so I don't know what is happening in SWC the compiler.
> I
> > > did
> > > > > write logic that climbs the super chain to find the method
> > signature. I
> > > > > said in a previous email that we can't use native because for some
> > > reason
> > > > > COMPC does't keep the optional args, weird I know.
> > > > >
> > > > > BTW, MouseEventInitis a @typedef and I havn't fully implemented
> them
> > > > > because they are weird and hard. :)
> > > > >
> > > > > Sometimes a @typedef could be a String, Boolean etc or an actual
> > > defined
> > > > > struct class.
> > > > >
> > > > > So I think I need some major logic to check whether it is a pointer
> > to
> > > a
> > > > > native type which it would be converted to that native type, or if
> > > it's a
> > > > > struct create the fields and this is where we would have to have a
> > > > > JavaScript transform. At compile time, you have the typed object
> but
> > in
> > > > > reality, it is just a plain {} object and not a javascript
> > > "type/class".
> > > > >
> > > > > I wasn't going to get into this typedef stuff until people started
> > > using
> > > > it
> > > > > because it isn't trivial.
> > > > >
> > > > > But now that you are, I can see what I can to to normalize it.
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > On Fri, Jun 26, 2015 at 12:24 PM, Josh Tynjala <
> > joshtynj...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Yeah, I think metadata would be acceptable too. If that seems
> > easier
> > > to
> > > > > > you, I say let's do that.
> > > > > >
> > > > > > I just found another issue in externc. I tried to subclass
> > > MouseEvent,
> > > > > > which is compiled into js.swc. It's not correctly determining the
> > > > number
> > > > > of
> > > > > > constructor arguments for MouseEvent, so when I try to compile
> the
> > > > > subclass
> > > > > > in AS3, it gives me this error.
> > > > > >
> > > > > > Error: Incorrect number of arguments. Expected 1
> > > > > > super();
> > > > > >
> > > > > > MouseEvent has two constructor arguments, so I think it should be
> > > > > emitting
> > > > > > super(null, null); instead.
> > > > > >
> > > > > > In fact, when I manually add w3c_events.js to my configuration,
> > then
> > > > > > externc correctly adds super(null, null);. So it seems to figure
> > out
> > > > the
> > > > > > number of constructor arguments from raw JS, but once the class
> is
> > > > > already
> > > > > > compiled into a SWC, it's losing that information somehow.
> > > > > >
> > > > > > - Josh
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 26, 2015 at 3:53 AM, Michael Schmalle <
> > > > > > teotigraphix...@gmail.com
> > > > > > > wrote:
> > > > > >
> > > > > > > 1) That is a bug, I think I hard-coded a quick fix on things
> that
> > > > have
> > > > > a
> > > > > > > @template tag and I immediately transformed them to Object
> > without
> > > > > > checking
> > > > > > > the for optional or var arg declarations. I can fix this, it's
> > only
> > > > > > methods
> > > > > > > with that tag and there are no very many.
> > > > > > >
> > > > > > > 2) Yeah, I figured as much, I had experience with Randori and
> > > pretty
> > > > > much
> > > > > > > knew this was going to come up.
> > > > > > >
> > > > > > > That way I see it is, the absolute minimum solution to this
> > problem
> > > > is
> > > > > > > getting the "problem" to be the same that is in IDEs today and
> > that
> > > > is,
> > > > > > you
> > > > > > > can't use two classes of the same name without having to
> qualify
> > > one.
> > > > > To
> > > > > > > me, this is a fix until this project gets momentum to go
> farther
> > > down
> > > > > the
> > > > > > > rabbit hole.
> > > > > > >
> > > > > > > I know Alex chimed in but here is my opinion from experience;
> > > > > > >
> > > > > > > Introduce a JavaScript tag that can be resolved at run-time to
> > > reduce
> > > > > the
> > > > > > > name back into it's native JavaScript identifier/package. I
> have
> > > gone
> > > > > > back
> > > > > > > and forth with Alex about this, asdoc verses metadata but,
> > metadata
> > > > > gets
> > > > > > > saved in a SWC and asdoc doesn't. For my ideas to work we must
> > have
> > > > > > > metadata in an external library to resolve the true javascript
> > > > > identifier
> > > > > > > when transpileing.
> > > > > > >
> > > > > > > [JavaScript(name=Event")]
> > > > > > > package org.apache.flex.dom {
> > > > > > > public class Event {}
> > > > > > > }
> > > > > > >
> > > > > > > IMHO to fix this, there has to be a sacrifice in one of the
> > > "links".
> > > > To
> > > > > > me
> > > > > > > that is putting the core classes in an apache.dom package and
> use
> > > the
> > > > > > > [JavaScript] metadata rewrite to reduce the package name during
> > > cross
> > > > > > > compile.
> > > > > > >
> > > > > > > With the above, you automatically solve all problems and only
> > > create
> > > > > one
> > > > > > > new one, you have to import DOM level classes. The EXTERNC
> > compiler
> > > > IMO
> > > > > > is
> > > > > > > still basic, it can understand basic package structures when
> > > defining
> > > > > > > externs, so we can have a createjs.Event and an
> > > > > > org.apache.flex.dom.Event.
> > > > > > > We can add a new config to the EXTERNC compiler that is
> > > > > > > -base-package="org.apache.flex.dom".
> > > > > > >
> > > > > > > We could also configure it to leave global constants, functions
> > in
> > > > > global
> > > > > > > namespace, as well as config a list of global classes such as
> > > Object
> > > > > and
> > > > > > > Array so this doesn't screw up inheritance and leave out the
> kewl
> > > > > > > document:HTMLDocument stuff.
> > > > > > >
> > > > > > > There are many details I would need to test and implement doing
> > > what
> > > > I
> > > > > > have
> > > > > > > described, but I already did it in the Randori compiler.
> > > > > > >
> > > > > > > As far as the other suggestions, since this is no-paid free
> > time, I
> > > > am
> > > > > > > looking for the quick solution that others don't think is out
> in
> > > left
> > > > > > > field.
> > > > > > >
> > > > > > > Let me know.
> > > > > > >
> > > > > > > PS I wish we could add on to the language, but from my
> > perspective
> > > > with
> > > > > > IDE
> > > > > > > support that isn't even an option...
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > > On Thu, Jun 25, 2015 at 8:06 PM, Josh Tynjala <
> > > joshtynj...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hey Mike,
> > > > > > > >
> > > > > > > > I finally got a chance to start playing around with some of
> > your
> > > > work
> > > > > > > > today. I've been starting out with externc. I've run into a
> > > couple
> > > > of
> > > > > > > > issues. One you already know about. Let's start with the
> other
> > > one,
> > > > > > > > though...
> > > > > > > >
> > > > > > > > 1) It looks like the Array class constructor has the wrong
> > > > signature.
> > > > > > > This
> > > > > > > > is from the es3.js extern:
> > > > > > > >
> > > > > > > > /**
> > > > > > > > * @constructor
> > > > > > > > * @param {...*} var_args
> > > > > > > > * @return {!Array.<?>}
> > > > > > > > * @nosideeffects
> > > > > > > > * @template T
> > > > > > > > * @see
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Array
> > > > > > > > */
> > > > > > > > function Array(var_args) {}
> > > > > > > >
> > > > > > > > It looks like externc is producing the following AS3:
> > > > > > > >
> > > > > > > > public function Array(var_args:Object) {}
> > > > > > > >
> > > > > > > > However, I think it's meant to produce this AS3 instead:
> > > > > > > >
> > > > > > > > public function Array(...var_args:Array) {}
> > > > > > > >
> > > > > > > > There are probably other functions with the same issue too.
> > > > > > > >
> > > > > > > > 2) I immediately ran into that issue where a top-level class
> > > > > interferes
> > > > > > > > with a class that has the same name in a package.
> w3c_event.js
> > > > > defines
> > > > > > > the
> > > > > > > > top-level Event class, and CreateJS has a createjs.Event
> class.
> > > > It's
> > > > > > the
> > > > > > > > exact same issue that you brought up earlier. I think I
> > dismissed
> > > > it
> > > > > > too
> > > > > > > > quickly. I apologize for that.
> > > > > > > >
> > > > > > > > At the time, I was thinking that FlexJS could easily work
> > around
> > > it
> > > > > > > because
> > > > > > > > be new code. However, now that I'm running into the collision
> > > > > > directly, I
> > > > > > > > realize that this is going to be a big issue with external
> > > > libraries.
> > > > > > > Like
> > > > > > > > CreateJS, a ton of existing JS frameworks define their own
> > Event
> > > > > type.
> > > > > > > This
> > > > > > > > issue is going to come up a lot. You're absolutely right: it
> > > needs
> > > > to
> > > > > > be
> > > > > > > > addressed somehow.
> > > > > > > >
> > > > > > > > I have some ideas. Some involve changes to the AS3 language.
> I
> > > > don't
> > > > > > know
> > > > > > > > if that's on the table, but I'll throw them out there anyway.
> > > > > > > >
> > > > > > > > If AS3 would let us do something like this, the issue
> wouldn't
> > be
> > > > as
> > > > > > bad:
> > > > > > > >
> > > > > > > > import global.Event;
> > > > > > > > import createjs.Event;
> > > > > > > > var event2:createjs.Event; //createjs
> > > > > > > > var event:global.Event; //native
> > > > > > > >
> > > > > > > > But AS3 doesn't provide any kind of identifier to refer to
> the
> > > > > > top-level
> > > > > > > > package. Even if it did, though, always being forced to use
> the
> > > > > > > > fully-qualified class name would get annoying. At least if
> > there
> > > > are
> > > > > > two
> > > > > > > > packages, you only need to do it when they're both imported.
> > With
> > > > one
> > > > > > > class
> > > > > > > > in the top-level, you always need to do it.
> > > > > > > >
> > > > > > > > Alternatively, TypeScript has some interesting import syntax
> > > that I
> > > > > > > > remember wishing we could use in AS3:
> > > > > > > >
> > > > > > > > import CreateJSEvent = createjs.Event;
> > > > > > > > var event2:CreateJSEvent; //createjs
> > > > > > > > var event:Event; //native
> > > > > > > >
> > > > > > > > Now, within the scope of the class with these import
> > statements,
> > > > > Event
> > > > > > is
> > > > > > > > the top-level function, and CreateJSEvent maps to
> > createjs.Event.
> > > > > This
> > > > > > > > would be really cool, in my opinion. I wish I could use it in
> > > > > Starling
> > > > > > > > projects to do exactly the same thing with event conflicts:
> > > > > > > >
> > > > > > > > import FlashEvent = flash.events.Event;
> > > > > > > > import starling.events.Event;
> > > > > > > > var event:Event; //starling
> > > > > > > > var event2:FlashEvent; //flash
> > > > > > > >
> > > > > > > > Again, that would require changes to AS3. Maybe that's not
> > > > > acceptable.
> > > > > > > >
> > > > > > > > Another option might be to make the name mapping configurable
> > as
> > > a
> > > > > > > compiler
> > > > > > > > argument:
> > > > > > > >
> > > > > > > > -map-class=createjs.Event,createjs.CreateJSEvent
> > > > > > > >
> > > > > > > > import createjs.CreateJSEvent;
> > > > > > > > var event:CreateJSEvent; //createjs
> > > > > > > > var event2:Event; //native
> > > > > > > >
> > > > > > > > or:
> > > > > > > >
> > > > > > > > -map-class=Event,NativeEvent
> > > > > > > >
> > > > > > > > import createjs.Event;
> > > > > > > > var event:Event; //createjs
> > > > > > > > var event2:NativeEvent; //native
> > > > > > > >
> > > > > > > > Very similar, but this would apply to a whole project instead
> > of
> > > > the
> > > > > > > scope
> > > > > > > > of a single class. The JavaScript output would use the real
> > name
> > > > > > > > (createjs.Event or Event), but the AS3 would use the mapped
> > name
> > > > > > > > (createjs.CreateJSEvent or NativeEvent).
> > > > > > > >
> > > > > > > > I suppose, with all of these, IDEs would probably fail to
> > > recognize
> > > > > > that
> > > > > > > > names were mapped and show incorrect errors. I'm finding this
> > > > > stagnant
> > > > > > > AS3
> > > > > > > > IDE landscape frustrating (IDEs have some annoying bugs with
> > the
> > > > > > Feathers
> > > > > > > > SDK too). It makes me want to forge ahead without them and
> hope
> > > > that
> > > > > an
> > > > > > > > alternative comes along.
> > > > > > > >
> > > > > > > > Thoughts? Please feel free to shoot things down for being
> crazy
> > > or
> > > > > > > > impossible.
> > > > > > > >
> > > > > > > > - Josh
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
