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
>
