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