Re: [vote] change ibehavior from interface to abstract class in trunk
... unless you feel IBehavior is no longer cohesive and needs to be
abandoned for that reason, or that it, or your new Behavior class
itself, should become an extension of multiple smaller interfaces that
more sensibly split, group and name the full range of
responsibilities, and if you are not proposing to widen or narrow the
API/functionality expected (of Behavior) by Component, wouldn't
public abstract class Behavior implements IBehavior{...}
be not only less disruptive but also not unnecessarily limit
design/implementation options open to app developers?
For example,
// this would need to be rewritten
final IBehavior myBehevior = new AjaxEventBehavior(onmouseover){...}
Beyond the stated relinquishment of proxies and mixins, this also
removes some implementation options when adapting to IBehavior (you
could still use delegation instead of implementation inheritance),
which may or may not be a smart practice, but why would Wicket take
responsibility for enforcing such judgement?
Other similar limitations would also be introduced, possibly without sufficient
compensation (1 less type to maintain?!)
For example,
// although this looks like a mixin too, the intention
// here is to adapt C to IBehavior's interface
class A extends C implements IBehavior{...}
Regards - Cemal
jWeekend
Training, Consulting, Development
http://jWeekend.com
On 27 November 2010 03:07, Igor Vaynberg igor.vaynb...@gmail.com wrote:
Vote is now closed with 4 binding +1 votes. I will work on implementing this
soon.
-igor
On Nov 26, 2010 11:47 AM, Martin Grigorov mgrigo...@apache.org wrote:
+1
On Wed, Nov 24, 2010 at 3:26 PM, Johan Compagner jcompag...@gmail.com
wrote:
+1
On Wed, Nov 24, 2010 at 03:22, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
the ib...
Re: [vote] change ibehavior from interface to abstract class in trunk
+1 On Wed, Nov 24, 2010 at 3:26 PM, Johan Compagner jcompag...@gmail.comwrote: +1 On Wed, Nov 24, 2010 at 03:22, Igor Vaynberg igor.vaynb...@gmail.com wrote: the ibehavior interface has become somewhat cluttered and a lot of methods in it can have a nice default implementation that works for 99% of the usecases. there is no longer a point to having it as an interface. this vote is to - rename IBehavior to Behavior and make it an abstract class with stubs for every method - rename AbstractBehavior to BaseBehavior and deprecate it, it has accumulated some crud over the years the only thing we will lose is the ability to cleanly proxy a ibehavior and to use it as a mixin - i cant think of any usecases for either vote ends 7pm gmt-8 friday the 26th -igor
Re: [vote] change ibehavior from interface to abstract class in trunk
Vote is now closed with 4 binding +1 votes. I will work on implementing this soon. -igor On Nov 26, 2010 11:47 AM, Martin Grigorov mgrigo...@apache.org wrote: +1 On Wed, Nov 24, 2010 at 3:26 PM, Johan Compagner jcompag...@gmail.com wrote: +1 On Wed, Nov 24, 2010 at 03:22, Igor Vaynberg igor.vaynb...@gmail.com wrote: the ib...
Re: [vote] change ibehavior from interface to abstract class in trunk
+1 On Wed, Nov 24, 2010 at 03:22, Igor Vaynberg igor.vaynb...@gmail.com wrote: the ibehavior interface has become somewhat cluttered and a lot of methods in it can have a nice default implementation that works for 99% of the usecases. there is no longer a point to having it as an interface. this vote is to - rename IBehavior to Behavior and make it an abstract class with stubs for every method - rename AbstractBehavior to BaseBehavior and deprecate it, it has accumulated some crud over the years the only thing we will lose is the ability to cleanly proxy a ibehavior and to use it as a mixin - i cant think of any usecases for either vote ends 7pm gmt-8 friday the 26th -igor
Re: [vote] change ibehavior from interface to abstract class in trunk
+1 -igor On Tue, Nov 23, 2010 at 6:22 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the ibehavior interface has become somewhat cluttered and a lot of methods in it can have a nice default implementation that works for 99% of the usecases. there is no longer a point to having it as an interface. this vote is to - rename IBehavior to Behavior and make it an abstract class with stubs for every method - rename AbstractBehavior to BaseBehavior and deprecate it, it has accumulated some crud over the years the only thing we will lose is the ability to cleanly proxy a ibehavior and to use it as a mixin - i cant think of any usecases for either vote ends 7pm gmt-8 friday the 26th -igor
