Probably time to re-open this debate... As I understand it, there are 3 issues:
1. When migrating code, it is important to where your code is relying on Flash APIs that aren't supported by FlexJS, but if UIBase extends Sprite the compiler will happily let your code make calls to Sprite APIs. 2. In code completion in Flash Builder and maybe other IDEs, lots of non-FlexJS APIs are offered. 3. When migrating code, an override of a SWF-only API will result in a compile error when compiling for JS since that API has no base class implementation on the JS side. And vice versa. Wrapping Sprite solves all of these problems, but introduces new ones like the need for a new event subsystem, and adds runtime and download overhead to every SWF. I would rather solve these problems in the compiler so there is no runtime overhead. Here are my latest thoughts: A) We could require the exact same API surfaces on both SWF and JS but that seems like excessive overhead. Would it be so bad if your code might run into a compile error during the JS compile if the SWF compile comes out clean? I think that's a reasonable price to pay so everyone doesn't have to pay download and runtime overhead. B) I don't use Flash Builder code completion myself since I pretty much know the APIs. When folks use it, do they want all public APIs or would they really want the list to be filtered to "usable" APIs. For example, in Flex UIComponent, there are public APIs like the "initialized" property that application developers should not be setting. I'm wondering if we should create different SWCs that have different APIs filtered on ASDoc directives so the "application" version of the SWC doesn't show APIs you shouldn't be using in building your app. Of course, when you finally output something to run, you may still get errors if you used APIs we hid from you. Having filters in ASDoc would also help ASDoc filter away APIs most folks won't need. Thoughts? -Alex
