We've adopted the new MVP framework pretty heavily in a couple of new projects and at this point, I don't think we've ever not used AbstractActivity. So, as long as the existing methods in Activity don't become inaccessible to non-GWT code (i.e. not package protected or final), I don't see a problem.
My only concern is that while making it an abstract class makes it easier to evolve, it also make it easier to default behavior that the end-user may not want. If a mechanism isn't provided to override this behavior, then someone may end up having to roll their own MVP framework for an otherwise minor issue. With a something as powerful and complex as this framework, that'd be a real shame. So, *please please please,* be cautious with this power: reasonable default behavior and the ability to override. Thanks! - Amir On Thu, Dec 2, 2010 at 7:55 PM, Ray Ryan <[email protected]> wrote: > We're making a few breaking changes in 2.1.1 to the new features introduced > in 2.1. (We're not supposed to do that kind of thing, but are hoping to get > away with it in this quick follow up release before there is much > adoption.) > > I'd like to add a change to Activity to that list, in order to allow it to > evolve in later releases when breakage of any kind won't be an option: I'd > like to make Activity an abstract class instead of an interface, basically > rename AbstractActivity. > > Any objections? > > rjrjr > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
