@Scott Thanks for the insight into the discussions. Maybe this will be something possible to add in the future, in some form.
@Bruce I like what I see with the UIBinder methodology... However, there is some amount of incompatibility with the MVP approach, unless I'm mistaken. This is because all Composite classes require GwtTestCases, whereas a presenter-layer Handler class would be JUnit testable. Have there already been thoughts about integrating the concepts of MVP and UIBinder? What searching I've done hasn't turned up much. I would love to see a discussion about combining MVP and UIBinder (though that's probably a topic for a different thread). On Nov 3, 11:36 am, Matt Mastracci <[email protected]> wrote: > I think the impact of anonymous classes will be significantly less > once union types are implemented. As it stands right now, every > anonymous class gets typeinfo and getClass because some code elsewhere > is calling it on an variable that can't be tightened more than Object. > > On 2009-11-03, at 10:23 AM, 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 -~----------~----~----~----~------~----~------~--~---
