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