Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Neil Fuller
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

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Ray Ryan
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

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Patrick Julien
making it a class instead of an interface means we can't mock it anymore. On Thu, Dec 2, 2010 at 10: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

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Ray Ryan
Any part of my point is that making sure it remains a trivial class with only no-ops means you don't need to mock it. Is that a reasonable assumption? On Fri, Dec 3, 2010 at 11:11 AM, Patrick Julien pjul...@gmail.com wrote: making it a class instead of an interface means we can't mock it

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Patrick Julien
I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. On Fri, Dec 3, 2010 at 2:20 PM, Ray Ryan rj...@google.com wrote: Any part of my point

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread John Tamplin
On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien pjul...@gmail.com wrote: I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. I have

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Patrick Julien
This is more in line with what we're doing. With what we experienced with the ramp up to 2.1.0, we only use the Activity interface, we don't use the default implementation and instead make our own for common classes of use cases. On Fri, Dec 3, 2010 at 3:02 PM, John Tamplin j...@google.com

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Ray Ryan
Patrick, you're the case in point. Because you don't use the abstract class, if we change the API later we will break your app. Were you unable to use the abstract class? If the Activity interface were documented to encourage you to do so, would you have? When we break your app, will you be okay

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Amir Kashani
I don't know what features are planned or contemplated beyond what Neil mentioned, but could the use of sub-interfaces help? For example, Neil's feature (+1 BTW) might use a PlaceAwareActivity which extends Activity? AbstractActivity can potentially implement them all new sub-interfaces. The

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Ray Ryan
One more question for Patrick: would you be better able to use AbstractActivity if the IsActivity interface were available? On Fri, Dec 3, 2010 at 12:18 PM, Ray Ryan rj...@google.com wrote: Patrick, you're the case in point. Because you don't use the abstract class, if we change the API later

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Patrick Julien
On Fri, Dec 3, 2010 at 3:18 PM, Ray Ryan rj...@google.com wrote: Patrick, you're the case in point. Because you don't use the abstract class, if we change the API later we will break your app. I guess I don't understand how you're making it better then. I'm currently working on Android and I

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-03 Thread Patrick Julien
On Fri, Dec 3, 2010 at 3:35 PM, Ray Ryan rj...@google.com wrote: One more question for Patrick: would you be better able to use AbstractActivity if the IsActivity interface were available? I don't want to speak for anybody else but not to me no. What AbstractActivity provides is so little that

[gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-02 Thread Ray Ryan
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

Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1

2010-12-02 Thread Amir Kashani
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