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. - Josh On Sep 18, 2015 10:28 PM, "Alex Harui" <aha...@adobe.com> wrote: > I’m still digging into the compiler, but I had some new thoughts: > > What if you only got an ambiguous definition error if you had two classes > neither of which is in the global package and didn’t qualify its usage? > This might be easiest to implement. If we did that, then: > > Scenario 1: > import flash.events.Event; > import org.apache.flex.events.Event; > > var foo:Event; // ambiguous definition error > > > Scenario 2 (using js.swc): > import goog.events.Event; > > var foo:Event; // always uses global package Event > var bar:Event = new goog.events.Event(); // error since bar is global > Event type > Var baz:Event = new Event(); // no error but instantiates global Event > > This would mean that, for folks using js.swc, you couldn’t just import > some class in a package that conflicts with a global package class and use > it without fully qualifying it. > > We could add a config option to warn instead of error on use of global > package classes. > > Even crazier, we could add an “unimport” directive or some compiler > option, asdoc tag, or metadata that does the same and tells the compiler > to never resolve to the global package. > > Thoughts? > -Alex > > On 9/18/15, 12:09 PM, "Alex Harui" <aha...@adobe.com> wrote: > > > > > > >On 9/18/15, 11:54 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > > >>Of the options that you presented, I think I like *.Event and .Event the > >>most. > >> > >>The options with :: don't feel quite right. While I know that packages > >>are > >>namespaces (I remember making that discovery back in the day and > >>excitedly > >>blogging about it), other classes aren't usually referenced with :: in > >>code. With that in mind, I like . better than :: because the . is more > >>consistent. If it were somehow easier to implement, though, I could live > >>with it. > >> > >>A simple string like global or null might conflict with some top-level > >>variable in user code or in the standard library of some JS environment, > >>so > >>I think that style should be avoided. > > > >Agreed. > > > >> > >>Of the two between *.Event and .Event, I'm not quite sure which I like > >>better. Which of these seems more readable? > >> > >>var myVar:.Event = new .Event(); > >> > >>var myVar:*.Event = new *.Event(); > >> > >>At first, I thought I liked *.Event better, but I might be preferring > >>.Event more now. > > > >Yeah, it might be easier grammar-wise to have something in front of the > >‘.’. I’m still digging into the compiler. I will report my findings and > >recommendations before committing anything. > > > >-Alex > > > >
