Responses inline. - Josh
On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui <aha...@adobe.com> wrote: > > Hmm. Maybe, but what does that sort of import really do? Why not just > create a global subclass of goog.events.Event? > A global subclass would work only if you were creating all instances. If you need to use the class as a method argument, where the arguments come from somewhere else that might not be using the subclass, the global subclass would not work: private function listener(event:GoogEvent):void //runtime error because it might receive goog.events.Event If what imports do is say, "every time that you find Event, replace it with goog.events.Event", then this new syntax would allow a little more flexibility "every time that you find GoogEvent, replace it with 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. > If the global Event can be used without any qualifier, this wouldn't be necessary. However, yes, I think I still like it the same. I would say that the most difficult thing to read is the colon followed by the dot (:.), but that was in the original example Another option is to throw in some double underscores to try to avoid naming conflicts: __global__.Event I think I'd still prefer .Event, though. > 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? > I had never considered window to be like a package before. That's a very interesting idea. It's worth noting that window has its own member variables too, so it's not only classes that are stored there. Will there be a conflict if both a window global variable and a window package exist? I guess, since AS3 supports variables and functions inside a package, window wouldn't necessarily need to be a global variable. We could just move everything into the package. externc would need to be updated with a new optional argument to say that globals should be put into a package. I think that this package name should be configurable, to support other hypothetical JS environments.
