This topic usually centers on all the little types needed for various event handlers. Happily, @UiHandler in UiBinder removes the whole issue. The UiBinder code generator can do whatever nastiness it needs to in order to create the most efficient event handler/dispatch code. IOW, it's not only more convenient to write your code using @UiHandler, it's almost certainly more efficient than what you'd create by hand even if you were willing to do the Hard Thing in your own handwritten code.
On Tue, Nov 3, 2009 at 12:23 PM, Scott Blum <[email protected]> wrote: > Hi Nathan, > > We've talked about doing something like this, under various names, > including "inner class elision". It seems worthwhile in the abstract, to > reduce client-side object counts. What I'm not sure of is how hard it > really would be to get right. In the past we've had discussions about the > attributes of the classes to be merged. They'd need to be singletons within > their containing class, final, initialized up front.. and references > wouldn't be allowed to "escape" into the wild. And that last one is the > real sticking point for what you want... allowing references to escape gets > very problematic, but not allowing them to escape makes it very hard to > actually get it to kick in for the exact case you're trying to solve. > > Scott > > On Tue, Nov 3, 2009 at 11:43 AM, Nathan Wells <[email protected]> wrote: > >> >> As I was developing this morning, I came across a trade-off that I >> wasn't happy with. Namely, as I create handlers and other interface >> implementations in a given class, the implementations create new >> classes, which adds additional, unnecessary code into the compiled >> output. >> >> One way around this is to sacrifice my code readability and simply >> have the containing class implement those interfaces. For example, >> >> class Foo { >> static class BarHandler implements ClickHandler, KeyDownHandler { >> ... >> } >> >> static class FooCommand implements Command { >> ... >> } >> >> ... class body that doesn't implement and onClick, onKeyDown or >> execute method... >> >> } >> >> could compile to something like >> >> class Foo implements ClickHandler, KeyDownHandler, Command { >> ... merged implementations ... >> } >> >> Of course, I'm operating under a few assumptions (based on my watching >> this group and the developer group, and my lack of knowledge about how >> the compiler actually works ;) >> >> 1. This isn't already done, >> 2. Adding more classes actually significantly increases the bulk of >> compiled output. >> 3. The amount of time to add this optimization would be less than the >> pain of the trade-off I'm dealing with. >> >> Let me know what you think, >> Nathan >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
