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