Right on Josh, that is exactly how I would have done it!~ Thanks!

Mike

On Fri, Jun 26, 2015 at 6:30 PM, Michael Schmalle <teotigraphix...@gmail.com
> wrote:

> Just to add, you probably figured it out, when I said emitClass(), I meant
> all of them, since you can't have any constants, classes, interfaces, enums
> or typedefs created for external externs.
>
> You get the idea. :)
>
> MIke
>
> On Fri, Jun 26, 2015 at 5:14 PM, Josh Tynjala <joshtynj...@gmail.com>
> wrote:
>
>> Okay, I looked over the source code. I think I understand how to implement
>> it. I'll give it a shot. Hopefully, I'll have something good to report
>> later today.
>>
>> - Josh
>>
>> On Fri, Jun 26, 2015 at 1:56 PM, Michael Schmalle <
>> teotigraphix...@gmail.com
>> > wrote:
>>
>> > On Fri, Jun 26, 2015 at 4:49 PM, Josh Tynjala <joshtynj...@gmail.com>
>> > wrote:
>> >
>> > > Yes, that makes sense. I incorrectly assumed it knew how to get that
>> > > information from SWCs too.
>> > >
>> > > So, if I understand you correctly, this -external-externs argument
>> > doesn't
>> > > exist yet? It still needs to be added to externc?
>> > >
>> >
>> >
>> > Correct, the EXTERNC client doesn't have any idea about the SWC in the
>> > first stage of javascript parsing, that is the closure compiler Java
>> API(no
>> > AS at all).
>> >
>> > The flag needs to be added to the configuration, ExternCConfiguration,
>> you
>> > then need to save the names in a list. Then during the emit stage, check
>> > the AST nodes which each ClassReference saves for the file name of the
>> > source and exlcude it if it is contained within the list during the
>> > emitClass() call.
>> >
>> > The above is how I would implement it, then nothing is generated for the
>> > external externs file.
>> >
>> > Mike
>> >
>> >
>> > > - Josh
>> > >
>> > > On Fri, Jun 26, 2015 at 1:29 PM, Michael Schmalle <
>> > > teotigraphix...@gmail.com
>> > > > wrote:
>> > >
>> > > > 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