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