You are definitely correct that Flash Builder does not necessarily pick up code hinting from the same SDK that you're using to compile the project. However, as I understand it, FB integrates with the AIR SDK with ASC 2.0 that is installed inside an Eclipse plugin at this location:
<FB4.7>/eclipse/plugins/com.adobe.flash.compiler_4.7.0.349722/AIRSDK Developers using FB 4.7 frequently replace it with new versions of the AIR SDK as they are released. I could be wrong. It could be that the code hinting integration in ASC 2.0 was not yet used in FB 4.7, and it was intended for a future version that never came to be. I guess it'll need some testing, assuming that Adobe wants to implement this feature too. I agree that this feature is best utilized by application developers, and not necessarily library/framework developers. Compatibility with the greater ecosystem is more important in the case of libraries. I probably wouldn't use this in the core Feathers library, but I definitely would in an app that uses Feathers. - Josh On Tue, Sep 27, 2016 at 8:45 AM, Alex Harui <aha...@adobe.com> wrote: > Fine with me. > > I would prefer that the basic component set of FlexJS not use this > feature. It might mess up ASDoc and some other places. I'm not clear > that FB 4.7 picks up the code-hinting from the SDK you are using. Also, I > often use grep when coding and aliases will mess up my results. > > But for NPM and Starling and places where there are lots of collisions > with existing library APIs, it sounds like a useful thing. > > -Alex > > On 9/27/16, 7:59 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > >I would like to propose a new feature for the ActionScript language in the > >Apache Flex "Falcon" compiler. It would be nice if developers could > >(optionally) rename an import. > > > >Background > >========== > > > >Normally when you import a class, you can reference the name of the class, > >without the package (unless there is another class with the same name): > > > >// begin example > > > >import com.example.ImportedClass; > > > >var example:ImportedClass; > > > >//end example > > > >I would like to make it possible to optionally rename the shortened > >version, like this: > > > >// begin example > > > >import NewName = com.example.ImportedClass; > > > >var test:NewName; > > > >//end example > > > >This would make it possible to resolve ambiguities without using the > >fully-qualified class name. Consider the following situation that commonly > >comes up when developing Starling apps where the fully-qualified name is > >required for different types of events: > > > >// begin example > > > >import flash.events.Event; > >import starling.events.Event; > > > >var one:flash.events.Event; > >var two:starling.events.Event; > > > >// end example > > > >If we could rename imports, our code wouldn't require cumbersome > >fully-qualified names. > > > >Consider the following example, references to FlashEvent will resolve to > >flash.events.Event and StarlingEvent will resolve to > >starling.events.Event: > > > >// begin example > > > >import FlashEvent = flash.events.Event; > >import StarlingEvent = starling.events.Event; > > > >var one:FlashEvent; > >var two:StarlingEvent; > > > >// end example > > > >In the next example, references to FlashEvent will resolve to > >flash.events.Event, similar to the previous example. References to Event > >can resolve to starling.events.Event without ambiguity because > >flash.events.Event has been given a different name. > > > >// begin example > > > >import FlashEvent = flash.events.Event; > >import starling.events.Event; > > > >var one:FlashEvent; > >var two:Event; > > > >// end example > > > >This would also be useful for transpile-to-JS workflow where the top-level > >package is littered with a ton of HTML classes that may conflict with > >names > >user-defined classes. For instance, there's a top-level Event class. There > >is no way to specify a different fully-qualified name for things in the > >top-level package, so it's hard to resolve ambiguity when using these > >classes. We have a bit of a workaround in Falcon by supporting a fake > >"window." package, but that's not ideal. Especially if you consider > >Node.js, which doesn't actually have a global window object. > > > >Risks and Challenges > >=================== > > > >* Renaming imports is a completely optional feature. Anyone can continue > >to > >code in ActionScript without ever using renamed imports. > >* Existing code won't be broken by this new feature. Regular imports that > >don't do any renaming will continue to work the same as they always have. > >* Runtimes like Adobe Flash Player will not need to be modified to support > >renaming imports. Imports are completely resolved at compile-time. > >* A SWC compiled from code with renamed imports will work with compilers > >that don't support renaming imports. Again, a SWC contains compiled code, > >so imports were already resolved. > >* I have implemented this feature already, in a local branch of > >flex-falcon > >on my machine. The code already exists, and it works today. > > > >The one tricky thing is that most IDEs probably won't play well with code > >that uses renamed imports. My NextGenAS extension for VSCode should have > >no > >problem because it loads the Falcon compiler from the Apache FlexJS SDK > >for > >its code intelligence features. If Falcon supports it, so will the > >extension. Adobe Flash Builder uses ASC 2.0 in a similar way, as I > >understand it. With that in mind, Flash Builder won't understand code with > >renamed imports unless Adobe modifies ASC 2.0 to add the same feature. I > >think third-party IDEs (like IntelliJ IDEA and FDT) have their own code > >models (rather than talking to the compiler), so they'd need to make their > >own changes to support this feature too. > > > >I would like to contact the Flash runtimes team at Adobe and ask if they'd > >be willing to implement this feature in ASC 2.0 too. It's a small change, > >but useful for developer productivity, so it should be well received by > >the > >community. Additionally, since it will affect the compiler and not the > >runtime, it will be significantly less risky for Adobe than other new > >language features might be. Finally, considering that the Falcon and ASC > >2.0 codebases are probably still extremely similar, I wouldn't be > >surprised > >if the changes were exactly the same. To go back to the previous point > >about IDEs, I'm pretty sure that if ASC 2.0 supports this feature, Flash > >Builder will get it for free when someone upgrades the AIR SDK used by the > >FB plugin. There may still be some quirks (I'm curious to see if > >organizing > >imports breaks or not), but I think ActionScript developers are used to a > >few occasional quirks these days. > > > >Comments welcome. > > > >- Josh > >
