The overhead to swfs seem to me like it’s really minimal. There’s not a lot of added code for using composition rather than inheritance.
Improving events is probably something which should be done for the JS side as well, so I’m not convinced that’s a major problem either. Some of the event issues we had had nothing to do with inheritance vs composition of Sprite and friends. It had to do with the fact that MouseEvent and Event are unrelated. Additionally, I really don’t believe most folks will use swf output for much more than debugging purposes, so if there’s a little more overhead, so what? Yes. Method and attribute conflicts were a major problem for us. This is especially true for code which is migrated from Flash. You get no compiler warnings, but things do not work as expected. We’ve also done a lot of work on the sprite-refactor branch which would be hard to back-port. In short, I think we should stick with composition and deal with the few issues it causes. On Sep 27, 2016, at 10:43 PM, Alex Harui <aha...@adobe.com> wrote: > 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 >
