> Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with > code-hinting in the IDEs and issues with property and method names with > low-level Flash APIs.
A bigger issue was related to defining properties and methods which collided with Flash ones. That’s not just a tooling issue. It’s not possible to define the properties and methods without overrides, and overrides generally do not work because they are incompatible. I don’t think wrapping things on the Flash side adds an unacceptible amount of overhead. It’s not worse that classic Flex components (probably a lot better) in that regard. On Aug 18, 2016, at 9:38 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 8/18/16, 10:42 AM, "Peter Ent" <p...@adobe.com> wrote: > >> I think I'm leaning more toward agreeing with you, Harbs, about a Flex >> event bus. I remember changing MouseEvent because of some issue (have to >> look at the logs) with it being a subclass of Event. If we make it a rule >> that every FlexJS component only work with org.apache.flex.events.Event >> (or a subclass), and have a set of interactive event (mouse, touch, >> keyboard) classes (which derive from our own Event class), something deep >> down should be able to translate platform events to our events and put >> them onto our bus. It is a shame not to take advantage of the platform's >> own dispatching system, but when trying to put things together from >> different systems, sometimes you need to go outside the box. > > Duplicating the event system is definitely a possibility, but I would like > to explore other solutions first. > > Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with > code-hinting in the IDEs and issues with property and method names with > low-level Flash APIs. It occurred to me that the wrapping solution might > be attacking this problem incorrectly: it is adding runtime overhead for > an author-time problem. That isn't PAYG. Further adding a duplicate > event system will only add more runtime overhead. The Google event system > we use on the JS side added 6K to every download. Not sure how big a > Flash version will be, but it will double the number of event listener > arrays and worse, the duplicates will be in ActionScript instead of C > code. And when you add overhead, you invite others to undercut you with > lower-overhead alternatives and fracture the community. > > In addition, IMO, it was a goal to try to abstract away the internal > implementations of the components. I'm concerned that we will get used to > wrapping everything. The CreateJS code and another Canvas framework that > doesn't have to wrap HTMLElements shouldn't have to wrap elements. Same > will be true for any Flash 3D/Starling/Feathers sort of thing for the SWF. > > So maybe the answer is to upgrade the tools to solve the original set of > problems. Then the runtime is as efficient as it can be for each platform. > > The separate problem of event classes and their inheritance is, IMO a > separate problem and the solution is dependent on whether we keep wrapping > DisplayObjects in the SWF implementation. I will say, though, that it is > important to remember that we want the lowest overhead on the JS side, so > having some additional overhead on the SWF side is ok, but double the > number of objects may be too much. Further, 100% compatibility with Flex > is not a requirement. So, some old Flex coding patterns and expectation > may have to change, including whether you have to get the type of your > events correct because MouseEvent doesn't subclass Event. That might still > be better fixed with better tooling and debugging. I can imagine some > hybrid apps where the app uses more than one library which are dispatching > different kinds of events. > > I am going to go dig up the original thread and respond there with a > discussion on alternative solutions. > > My 2 cents, > -Alex >
