Basically we don't know exactly how we want to change the thing, but have a feeling something will be needed. Re: composition or delegation, it always happens, but I'm not sure that's a concrete issue yet. We could introduce an IsActivity interface, but I don't see anywhere in the current GWT code we would actually call it. People implement their own ActivityMappers by hand, so they could use that convention themselves.
Sounds like there aren't super strong feelings on this, so today for 2.1.1 I'm inclined to - drop the interface - rename AbstractActivity to Activity - document as being forbidden from developing any non-trivial behavior - and perhaps document the intent to retroactively introduce an interface when it's had a chance to settle Last passionate objections? On Tue, Dec 7, 2010 at 8:31 AM, PhilBeaudoin <philippe.beaud...@gmail.com>wrote: > Tell me if I get this right, but the most important advantage of > having only an abstract class is that you are guaranteed your user > extends the abstract class instead of implementing the interface, > which let you easily extend it later (i.e. add methods) without > breaking existing user code? > > On the other hand, it looks like, in a world of unchanging APIs, the > interface might be the best way to go, facilitating things like reuse > via a composition/delegation pattern. For example, MyPresenter could > inherit from BasePresenter class and implement Activity, delegating > all the calls to a composed AbstractActivity. Without an interface I > would have to refactor BasePresenter to inherit from the Activity > abstract class, making it impossible to have non-activity presenters. > > So it looks to me like it boils down to: > 1) How likely is it that the Activity interface evolves in a way that > would not be handled by adding subinterfaces or extra interfaces? > 2) How frequently are users expected to compose/delegate with > Activity? > > A concluding remark: GWTP went the abstract class way for its > hierarchy of Presenter classes. It makes it quite easy to use, but the > composition problem has reared its ugly head a couple of times. If I > had to do it again I would use interfaces and favor composition of > default implementations. > > Cheers, > > Philippe > > On Dec 6, 5:05 am, Jeff Larsen <larse...@gmail.com> wrote: > > Personally, I'm a fan of having both. The default implementation can > > be an abstract class but have that abstract class implement the > > Activity interface. Developers will be making a conscious choice to > > use the interface only knowing that they can introduce bugs. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
