On 7/27/16, 1:27 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>The only class which still subclasses Sprite is Application. I don’t >>>know >>> a way around that. >> >> One idea is that, since developer code never instantiates an Application >> (only the framework does) that Application could be an interface. The >> framework would instantiate the concrete class. > >Not sure how to go about this, but I’m not sure how bad it is for the >main app to subclass Sprite. I’ll leave this for someone else.
If we don't fix this, the Application code-hinting will show all the Flash stuff. > >>> >>> The big question here is how to handle events. We could attach event >>> listeners for every conceivable event and forward the events out. I’d >>> like to avoid that if possible. I’m wondering if there’s a way to >>> override addEventListener and removeEventListener so we’d only attach >>> event listeners when we know someone is listening for them. >> >> Doesn't the JS side already have a solution for this? addEventListener >>on >> the wrapper calls addEventListener on the wrapped element for certain >> events. > >Not sure. There is some goog-specific event proxying, but I’m not exactly >sure what it’s doing. I guess we could add specific events as needed, but >I think it would be really great if it could happen automagically. How >much overhead is there by adding a whole list of event listeners for >every object created? TextField has 78 possible events. I’m not sure how >many are going to be needed, but potentially a lot. Here’s the idea that >I’m thinking of: If every instance had 70 function calls, I think you'd see that in the profilers. Let me see if I can get through this one bug I'm working on, then I'll grab the branch and see about the Application-as-interface and implementing a similar event proxy scheme. -Alex
