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