Inline as well, gotta scroll way down for my latest proposal. On 9/19/15, 9:01 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>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". Well, that would be a big and scary change. For some reason I don’t know, imports open namespaces for multi name lookups at runtime. What’s interesting about the TS import is it puts you on the slippery slope towards preprocessor macros. > > >> 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. Actually, we’ve already hit this trying to stub GCL for FlexJS. GCL has functions and variables on goog.events like goog.events.fireListener, and then classes like goog.events.EventTarget. I don’t recall any AS variables/properties on packages in AS3 because I think packages are not objects in AS3 like they are in JS. So we created a class in the goog package called events (lower case) and put the same variables GCL puts on its JS goog.events object. One of my latest commits changes the compiler to try goog.events as both a package and a class. So yes, in theory we would have a class in the default package called “window” but also classes in the “window” package called Events. > >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. Well, that’s true if we do it the “legitimate” way. But that might also force everyone using js.swc to start every file with “import windows.*” which is acceptable to me, but let me describe a possible “hack”. I think we could make “window” a special word in FalconJX and when creating package namespaces, collapse it down to “” (empty string) which is equivalent to the default package. Then, if you are just writing plain JS and don’t import any other class called Event, you can just use Event without any import statement or package prefix and it would just work. No changes to ExternC or any existing code. Then, if you import an Event class like goog.events.Event, the AmbiguousDefinition logic would look at the file scope to see if there was an “import window.Event;”. If there isn't, it will assume you meant goog.events.Event because not importing window.Event would mean you never intended to use the class in the default package. It would be only in the rare case where you import both goog.events.Event and window.Event that you would start getting AmbiguousDefinition errors and have to fully qualify the plain Event as window.Event, and the output would not be prefixed with “window”. And what I like more about this sort of hack (or doing it the legitimate way) is that it doesn’t introduce new “unexpected” syntax like “.Event”. Thoughts? -Alex
