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
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
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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo