On 9/19/15, 7:43 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>I think that making it possible to reference a class in the global >package, >even when another class with the same name is imported, is a good >improvement. Probably easiest to implement. > >Along the same lines as an unimport, what if we could do something like >this to remove ambiguity: > >import GoogEvent = goog.events.Event; > >TypeScript supports this kind of import, and it's very useful for removing >ambiguity. I really wish AS3 had it. It would have made importing both >Flash events and Starling events so much easier. Hmm. Maybe, but what does that sort of import really do? Why not just create a global subclass of goog.events.Event? BTW, I realized that the choices should have had more examples. Maybe: var foo:.Event; doesn’t looks so bad, but once you fill it out further: var foo:.Event = new .Event(); var bar:.Event = foo as .Event(); var baz:.Event = .Event(foo); Do we still like it? I think I have found one place to try to change to make it work. However, my new thought of the day is this: For SWFs, we can discourage folks from making conflicts with classes in the “global” package so this is really for JS users. But don’t folks doing native JS already have the option of using “window” as the package name? import window.Event; var foo:window.Event = new window.Event(); Could we auto-replace Event with window.Event when generating externs and then require folks to use window.Event when they want the “global” ones? -Alex
