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

Reply via email to