Full disclosure - I am the one who has suggested a possible evolution of Activity. I was suggested the introduction of a mechanism to allow an existing Activity to be informed when the Place has changed but the Activity has not (e.g. when there is a change in Place tokens). I commented about how difficult it would be to add a method to Activity without introducing a break and Ray kindly started this thread.
I agree with Amir about the concerns. The AbstractActivity class and the interface it implements has to have sensible, obvious, do-nothing implementation otherwise subclasses have to override the behavior they don't want and it all gets messy. Also, in Java we get to have one base class, so extending AbstractActivity precludes extending something else. Several APIs I've worked with have moved away from a design that requires developers to extend a particular class. e.g. JUnit Removal of the interface entirely would make mocking with frameworks like EasyMock more difficult. Although things like the EasyMock classextension make it possible to mock non-interfaces it's not ideal and obviously isn't an option in a GWT test case. Personally I'd like to try to keep the interface for these reasons. How about the documentation is beefed up on the interface to say "You should extend AbstractActivity rather than implement Activity directly otherwise you may be broken" if it doesn't already, but leave the interface in place for people who want to take on the risk of a break? I guess it depends on how much Activity is expected to change in future. In the case I have in mind to Activity the implementation would probably have an obvious no-op implementation, but without having talked about that it's hard to be sure. Luckily, I'm pretty sure that the use of AbstractActivity is what most people will have done anyway. I've just started looking at the Activity framework and this particular wrinkle was the first we hit, but I wonder how many more things the ActivityManager (and associated classes) would want to call on the Activity interface so the need to evolve Activity much further may not be required. I do agree that now would be a good time to do this kind of change, though, because it's only going to get harder. Neil. On 3 December 2010 05:39, Amir Kashani <[email protected]> wrote: > >> 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 >> >> >> > > > -- > Google UK Limited > > Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W > 9TQ > Registered in England Number: 3977902 > -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
