On 8/18/16, 10:42 AM, "Peter Ent" <[email protected]> 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
