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