Let me push harder for the abstract class. If the class is documented to
forbid non-trivial default implementations, there would be no need to mock
it, and no chance of breaking people who decide to use the interface
directly for whatever reason.
WRT to the single base class problem, I was initially going to propose that
we also add interface IsActivity { Activity asActivity(); } and make
Activity implement it. But I didn't see any immediate use for it, since
nothing at the moment accepts an Activity as an argument, and nothing
returns one except for ActivityMapper. If such a need appeared it would be
trivial to add.
You buying it? Is the loss of easyMock too much?
On Fri, Dec 3, 2010 at 12:36 AM, Neil Fuller <nful...@google.com> wrote:
> 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 <amirkash...@gmail.com> 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 <rj...@google.com> 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
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
