On 6/25/15, 5:06 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: >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.
Some thoughts on this: 1) IMO, there’s a difference between changing the language and changing the compiler. We own the compilers and can do pretty much whatever we want to it. 2) You are correct that IDE’s may not be happy with any changes, but the fact is that FB already has an old pre-Apache version of Falcon (known as ASC2.0) in it. It would show yellow squiggly lines in totally legal places because it had bugs. I haven’t tested if the yellow lines still show up now that we use Falcon as the oem-compiler. If they went away, then we do have pretty good control over FB. If they haven’t, folks have learned to live with them and only focus on the red squiggly lines which definitely come from the oem-compiler and thus we definitely control, so there is some opportunity for change there. No idea how IJ would handle a compiler change. 3) One option we have is to use non-AS3 directives via Metadata or even special ASDoc tags. Most .as files also have these two other languages mixed in and it doesn’t change the language and can get the compiler to do certain things differently. I am using special ASDoc tags in FlexJS already 4) There is an in-line namespace syntax like when you write mx_internal::some_mx_internal_variable. I haven’t tested to see if global classes can be addressed as ::Array or .Array or something like that. I’ll have to try to find time to walk through Falcon’s resolver and see if there is some syntax that already works or would be easy to make work. 5) Falcon now allows for a customizable set of default imports for MXML so there is opportunity to muck with what is auto-imported. We might be able to extend that notion to AS files. Then maybe we can auto-import a global package and then have the compiler auto-resolve that to the top-level ones. -Alex
