Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
Exactly, this is where I ran into this. On Fri, Dec 17, 2010 at 3:36 AM, Thomas Broyer wrote: > > On Wednesday, December 8, 2010 9:16:16 PM UTC+1, PhilBeaudoin wrote: >> >> Just ran into an interesting little hack today. Basically, the interface >> includes a method: >> >> public void __do_not_implement_this_interface_extend_FooImpl_instead(); >> >> I'm far from convinced I like it, but it sure is right in your face in >> case you don't read javadocs! ;) > > interestingly, that's exactly what Hamcrest (used in many testing tools: > JUnit, Mockito, etc.) does: > http://code.google.com/p/hamcrest/source/browse/trunk/hamcrest-java/hamcrest-core/src/main/java/org/hamcrest/Matcher.java?r=645 > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On Wednesday, December 8, 2010 9:16:16 PM UTC+1, PhilBeaudoin wrote: > > Just ran into an interesting little hack today. Basically, the interface > includes a method: public void __do_not_implement_this_interface_extend_FooImpl_instead(); I'm far from convinced I like it, but it sure is right in your face in case > you don't read javadocs! ;) interestingly, that's exactly what Hamcrest (used in many testing tools: JUnit, Mockito, etc.) does: http://code.google.com/p/hamcrest/source/browse/trunk/hamcrest-java/hamcrest-core/src/main/java/org/hamcrest/Matcher.java?r=645 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On Thu, Dec 9, 2010 at 1:04 PM, Ray Ryan wrote: > Nnnnevermind. I think it's too late for me to make this > not-terribly-popular change. It's already more widely adopted than I > realized internally, so I have to assume that's even more true externally. I > can't imagine such a break being well received. I think it's for the best. > (Yes, we're making more significant changes to RequestFactory in 2.1.1, but > I suspect that has a lower adoption rate so far, and client side the impact > is actually fairly minimal, except for the dropped UserInfo stuff.) That and RequestFactory on the server is still pretty hellish effort wise. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On Thursday, December 9, 2010 7:04:39 PM UTC+1, rjrjr wrote:Nnnnevermind. I think it's too late for me to make this not-terribly-popular change. It's already more widely adopted than I realized internally, so I have to assume that's even more true externally. I can't imagine such a break being well received. If you mean that the "temporary rollback" on trunk is finally not "temporary", then do not forget to roll it back on releases/2.1 too ;-) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
Nnnnevermind. I think it's too late for me to make this not-terribly-popular change. It's already more widely adopted than I realized internally, so I have to assume that's even more true externally. I can't imagine such a break being well received. (Yes, we're making more significant changes to RequestFactory in 2.1.1, but I suspect that has a lower adoption rate so far, and client side the impact is actually fairly minimal, except for the dropped UserInfo stuff.) rjrjr On Wed, Dec 8, 2010 at 3:53 PM, Thomas Broyer wrote: > > > On Wednesday, December 8, 2010 8:22:39 PM UTC+1, John A. Tamplin wrote: > > On Wed, Dec 8, 2010 at 2:17 PM, Ray Ryan wrote: > >> 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? >> > > I still feel like there is little cost in having the interface, which is > what is used in the API, and a default implementation where any new methods > added will get default behavior. Then document that if you implement the > interface but don't extend the default implementation, you will be broken by > future updates. That lets users decide whether they care more about not > being broken by updates or more about not having to extend a base class. > > > +1 > > Though I'm OK with the proposed (abstract)Activity and SimpleActivity (i.e. > just make Activity an abstract class rather than an interface –with all > methods being abstract– and rename AbstractActivity into SimpleActivity, > rather than just renaming the current AbstractActivity to Activity, with the > no-op methods) > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On Wednesday, December 8, 2010 8:22:39 PM UTC+1, John A. Tamplin wrote: On Wed, Dec 8, 2010 at 2:17 PM, Ray Ryan wrote: 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? I still feel like there is little cost in having the interface, which is what is used in the API, and a default implementation where any new methods added will get default behavior. Then document that if you implement the interface but don't extend the default implementation, you will be broken by future updates. That lets users decide whether they care more about not being broken by updates or more about not having to extend a base class. +1 Though I'm OK with the proposed (abstract)Activity and SimpleActivity (i.e. just make Activity an abstract class rather than an interface –with all methods being abstract– and rename AbstractActivity into SimpleActivity, rather than just renaming the current AbstractActivity to Activity, with the no-op methods) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
Just ran into an interesting little hack today. Basically, the interface includes a method: public void __do_not_implement_this_interface_extend_FooImpl_instead(); I'm far from convinced I like it, but it sure is right in your face in case you don't read javadocs! ;) Philippe On Wed, Dec 8, 2010 at 12:11 PM, Ray Ryan wrote: > I hope that doesn't come across as having ignored Neil, John et al. I do > prefer using interface + abstract class, but I don't really believe that > people actually read JavaDoc, and I'm certain we need to mess with this > interface just a bit more. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
I hope that doesn't come across as having ignored Neil, John et al. I do prefer using interface + abstract class, but I don't really believe that people actually read JavaDoc, and I'm certain we need to mess with this interface just a bit more. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On Wed, Dec 8, 2010 at 2:17 PM, Ray Ryan wrote: > 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? > I still feel like there is little cost in having the interface, which is what is used in the API, and a default implementation where any new methods added will get default behavior. Then document that if you implement the interface but don't extend the default implementation, you will be broken by future updates. That lets users decide whether they care more about not being broken by updates or more about not having to extend a base class. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
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 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 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
[gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
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 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
[gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
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
[gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
Sorry for being so prescriptive in my first email about interfaces and
mocking and starting a bit of a side discussion about interfaces Vs
abstract classes. It smells a little like a no-one-right-answer
discussion that has probably been debated in every API forum.
I think most people could live comfortably with each approach.
However, I've seen many cases of frameworks starting out with abstract
(or concrete) classes and then going through pain of introducing
interfaces when the problems crop up. I think it would be a shame to
go the other way. GWT is going through to the trouble of introducing
IsWidget, etc., presumably to support better composition. In GWT's
case that's always smelled to me like something that might have been
done differently if the designers could start with a clean slate. If
the convention in GWT it to have Is{Abstract|Concrete} and a default
implementation of the interface then it might be worth moving to that
model for consistency, but that would probably break even more code!
The Interface Vs AbstractClass discussion so far seem to break into
the two main points:
1) Multiple inheritance.
2) Mocking
My view:
1) Multiple Inheritance:
I think the problem usually comes down to: What if a developer class
naturally behaves like an Activity and a "something-else", where
"something-else" is written in some framework the GWT team have no
control over and also requires you extend another Abstract class.
Well, then we get into writing shims like getAsActivity(),
getAsSomethingElse() to get around the Java single inheritance model.
With interfaces, internally, the implementer may well be using
delegation/composition to avoid writing the same code again. Use of
inheritance for code re-use rather than true specialization is
convenient, but I've become less tolerant to it over time when it is
presented as the only way to do things (rather than a convenience)
because it seems to cause a lot of pain.
2) On the mocking point - perhaps everybody uses EasyMock now and
that's ok. My understanding is that EasyMock won't work under standard
GWT tests (somebody please correct me if I'm wrong). The class
extension code is, IMO, a clever way of mocking classes that were not
written with an API / testing in mind. Having previously measured the
performance impact of mocking classes Vs interfaces I can tell you
there was at one point a measurable several-order-of-magnitude
difference in performance. I don't know if that's still the case but
the reason we looked at it at all was that our small tests were taking
many seconds to run and we couldn't work out where all the expense
might be coming from. That's not a compelling argument backed up by
evidence but something people might want to debunk if using mocking-of-
classes extensively.
I guess Activity may be so simple this isn't something that I should
be concerned about, but having had to hand-roll stubs/fakes/mocks for
classes that were never designed for testing in mind (and also not
very amenable to EasyMock-style expectation-setting) I tend to have a
knee-jerk "interfaces are good, abstract classes are bad" reaction.
One problem is, if somebody adds a method to AbstractActivity and I'm
hand-rolling test classes there's no compile time error to say that
I've forgotten to override a method and so my AbstractActivity is now
only partially mocked. Those can be fun to debug. The "easy to evolve"
advantage of an abstract class actually causes problems in this one
case.
The other problem for me is that if you have the following:
new MyClassUnderTest(fooActivity)
And fooActivity is of type FooActivity. The developer made it an
interface because a mocking framework didn't fit, or because that's a
project standard, or they wanted a fake, not a mock or a stub. The
internals of MyClassUnderTest cannot then take FooActivity and pass it
to something expecting an AbstractActivity (without a nasty, test-
breaking cast) even if the developer has go to the trouble of
declaring identical methods on FooActivity as are inherited from
AbstractActivity. I've hit this a few times and had to resort to
EasyMock-class extension, or the "override everything" approach to
writing mocks.
Just my 2c.
Neil.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On 3 déc, 04:55, Ray Ryan 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? We're not using AbstractActivity, but only because we do provide our own implementation for all the Activity methods, so AbstractActivity doesn't bring us anything. So, AbstractActivity replacing Activity wouldn't change anything for us (search "implements Activity" and replace with "extends Activity"). Moreover, we do have a base class (enforcing MVP "best practices") that almost all our activities extend, so the change would be very localized. In brief: no objection. I'd be OK too with keeping it an interface and instructing developers to rather extend AbstractActivity (that's something that has been proposed for widgets too). That being said, I don't understand the objections re. mocking (and EasyMock 3.0 now integrates class mocking, it's no longer an "extension"). The only issue with class mocking is final methods, and the existing methods won't become 'final' and that would break a lot of apps; new methods introduced later have few reasons to be 'final', and if they ever are the'll delegate to non-final ones so mocking will still be possible to some extent. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
