You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Eelco Hillenius <ee...@gmail.com> on 2006/12/06 19:15:23 UTC
VOTE: make all onComponentTag and onComponentTagBody methods non-final
I think using final for the onComponentTag and onComponentTagBody
methods have served their purposes fine during our wild two years of
development, but our core components are now stable enough to not have
to be worried about painting ourselves in the corner when we would
open up these methods (ie remove final).
Please vote:
[ ] yes, make all onComponentTag and onComponentTagBody methods of
the standard components in core non-final. This does leave the door
open for specific components to not adhere to that - I'm not proposing
a new standard - but if this wins we would remove final for most of em
[ ] no, leave the code as it is now
Eelco
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Johan Compagner <jc...@gmail.com>.
yes fine.
On 12/6/06, Eelco Hillenius <ee...@gmail.com> wrote:
>
> Is that a +1 on my proposal?
>
> Eelco
>
> On 12/6/06, Johan Compagner <jc...@gmail.com> wrote:
> > just look if there is not a gotcha somehow that we can open
> > for the method you want to remove final.
> > If you can't think of one then remove it.
> > Just look at this method for method
> >
> > johan
> >
> > On 12/6/06, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > I think using final for the onComponentTag and onComponentTagBody
> > > methods have served their purposes fine during our wild two years of
> > > development, but our core components are now stable enough to not have
> > > to be worried about painting ourselves in the corner when we would
> > > open up these methods (ie remove final).
> > >
> > > Please vote:
> > > [ ] yes, make all onComponentTag and onComponentTagBody methods of
> > > the standard components in core non-final. This does leave the door
> > > open for specific components to not adhere to that - I'm not proposing
> > > a new standard - but if this wins we would remove final for most of em
> > >
> > > [ ] no, leave the code as it is now
> > >
> > > Eelco
> > >
> >
> >
>
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
Is that a +1 on my proposal?
Eelco
On 12/6/06, Johan Compagner <jc...@gmail.com> wrote:
> just look if there is not a gotcha somehow that we can open
> for the method you want to remove final.
> If you can't think of one then remove it.
> Just look at this method for method
>
> johan
>
> On 12/6/06, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I think using final for the onComponentTag and onComponentTagBody
> > methods have served their purposes fine during our wild two years of
> > development, but our core components are now stable enough to not have
> > to be worried about painting ourselves in the corner when we would
> > open up these methods (ie remove final).
> >
> > Please vote:
> > [ ] yes, make all onComponentTag and onComponentTagBody methods of
> > the standard components in core non-final. This does leave the door
> > open for specific components to not adhere to that - I'm not proposing
> > a new standard - but if this wins we would remove final for most of em
> >
> > [ ] no, leave the code as it is now
> >
> > Eelco
> >
>
>
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Johan Compagner <jc...@gmail.com>.
just look if there is not a gotcha somehow that we can open
for the method you want to remove final.
If you can't think of one then remove it.
Just look at this method for method
johan
On 12/6/06, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I think using final for the onComponentTag and onComponentTagBody
> methods have served their purposes fine during our wild two years of
> development, but our core components are now stable enough to not have
> to be worried about painting ourselves in the corner when we would
> open up these methods (ie remove final).
>
> Please vote:
> [ ] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> [ ] no, leave the code as it is now
>
> Eelco
>
Re: Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> After deleting some heated, unsent messages (never post when angry, a
> very wise blogger told me), taking some time thinking about other
> stuff, I see that I misinterpreted your message. I'm sorry I misread
> you, I'm sorry I accused you of mal-intent. My sincerest apologies,
> the whiskey is on me with our next meeting (if I feed you enough, you
> might even forget it :-).
Whiskey++
> That said, I'm still not feeling comfortable removing final from all
> onComponentTag/onComponentBody methods.
Ok, I don't share that opinion and definitively think we're being too
zealous about it, but we're a team and different opinions can exist.
I'd like to propose a next vote with some specific cases of removing
final then. Will post later.
Eelco
Re: Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Martijn Dashorst <ma...@gmail.com>.
After deleting some heated, unsent messages (never post when angry, a
very wise blogger told me), taking some time thinking about other
stuff, I see that I misinterpreted your message. I'm sorry I misread
you, I'm sorry I accused you of mal-intent. My sincerest apologies,
the whiskey is on me with our next meeting (if I feed you enough, you
might even forget it :-).
That said, I'm still not feeling comfortable removing final from all
onComponentTag/onComponentBody methods.
Especially the onComponentBody method can lead to servlet style
programming which we shouldn't encourage. Just like
Component#setModelValue() or Component#getModelValue(). These are very
handy in specific cases where we want to do more basic processing, but
they do cloud the API and point new users towards a push way of
programming instead of the preferred pull model (this is not a call
for removing get/setModelValue).
I see that sometimes this is necessary (performance, memory footprint)
to override onComponentBody, but I hope we can find a better way of
achieving this goal, though it may not exist.
A current spot where we already removed final from onComponentTag and
onComponentBody is Panel where it is necessary to call super in both
methods. I am not sure when to call super.onComponentBody(): should it
come first or last? The only way I can be sure is to try it. But then
if the implementation of Panel changes, will I have to modify the call
sequence? Will we document such changes in our release notes? It is
something easily overlooked.
Martijn
--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>
Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> On 12/7/06, Eelco Hillenius <ee...@gmail.com> wrote:
> > Another example is Link with a label inside. I'm starting to get
> > irritated with the fact that even though a label rendering was
> > requested as part of it's default behavior, and at least some people
> > were pro that, it ended in a stale mate again, and that even the basic
> > facility for letting people do that themselves (letting them override
> > onComponentTagBody) is yet again a point of debate.
>
> And this is exactly why I am not +1. This is a covert attempt to get
> your way, even though the previous vote stranded.
What th are you talking about? A covert attempt? Please! This is an
attempt to provide people with the means to do it themselves.
Currently, people who want to make such a custom component have to do
a lot of code duplication because they can't do it by extending Link.
> > I don't believe we have to be that strict on these
> > methods anymore.
>
> I think some disagree here, as can be seen from the mixed reactions to
> your proposal.
Yeah, not the *I* please.
> > They served our purposes for protecting ourselves
> > against opening up too soon well, and as you can see from the history
> > of opening up these methods, there usually have been cases where it
> > made perfect sense, but we just didn't think about the use case
> > before.
>
> Therefore we ask with each opening of the API for a usecase. In your
> proposal the only usecase you give is that "it is time". Or your
> frustration that a previous attempt stranded.
I don't think you have to be insulting.
Eelco
Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Martijn Dashorst <ma...@gmail.com>.
On 12/7/06, Eelco Hillenius <ee...@gmail.com> wrote:
> Another example is Link with a label inside. I'm starting to get
> irritated with the fact that even though a label rendering was
> requested as part of it's default behavior, and at least some people
> were pro that, it ended in a stale mate again, and that even the basic
> facility for letting people do that themselves (letting them override
> onComponentTagBody) is yet again a point of debate.
And this is exactly why I am not +1. This is a covert attempt to get
your way, even though the previous vote stranded. The developer
community needs to be in line for such a change. This didn't happen
with the previous vote, so what makes you think this has changed?
> I don't believe we have to be that strict on these
> methods anymore.
I think some disagree here, as can be seen from the mixed reactions to
your proposal.
> They served our purposes for protecting ourselves
> against opening up too soon well, and as you can see from the history
> of opening up these methods, there usually have been cases where it
> made perfect sense, but we just didn't think about the use case
> before.
Therefore we ask with each opening of the API for a usecase. In your
proposal the only usecase you give is that "it is time". Or your
frustration that a previous attempt stranded.
In the onComponentTag change, I gave a usecase: memory consumption of
AttributeModifiers. Everything in onComponentTag can be achieved using
AttributeModifiers. However, they cost memory. If a component is used
a lot, then it is beneficial to be able to override this method, and
use it as a low-cost AttributeModifier. However, this doesn't imply I
want full control for this method on all components. For the record, I
could manage this using the existing non-final components.
Martijn
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
This:
add(new RequiredTextField("password", new PropertyModel(properties,
"password"))
{
protected final void onComponentTag(final ComponentTag tag)
{
super.onComponentTag(tag);
// clear the field after each render
tag.put("value", "");
}
});
is an example of where such overrides are handy.
Another example is Link with a label inside. I'm starting to get
irritated with the fact that even though a label rendering was
requested as part of it's default behavior, and at least some people
were pro that, it ended in a stale mate again, and that even the basic
facility for letting people do that themselves (letting them override
onComponentTagBody) is yet again a point of debate.
If people think it is a better idea to start a vote explicitly naming
those components/ methods, that's fine I'll do that. But like I stated
with the proposal, I don't believe we have to be that strict on these
methods anymore. They served our purposes for protecting ourselves
against opening up too soon well, and as you can see from the history
of opening up these methods, there usually have been cases where it
made perfect sense, but we just didn't think about the use case
before.
Eelco
On 12/7/06, Eelco Hillenius <ee...@gmail.com> wrote:
> > Please vote:
> [ x ] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> Eelco
>
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
So I have 2 binding +1, 1 non-binding +1 and 1 abstain? Can I have a
couple more votes please?
Eelco
On 12/7/06, Eelco Hillenius <ee...@gmail.com> wrote:
> > Please vote:
> [ x ] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> Eelco
>
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
> Please vote:
[ x ] yes, make all onComponentTag and onComponentTagBody methods of
the standard components in core non-final. This does leave the door
open for specific components to not adhere to that - I'm not proposing
a new standard - but if this wins we would remove final for most of em
Eelco
Re: VOTE: make all onComponentTag and onComponentTagBody methods
non-final
Posted by Erik van Oosten <e....@chello.nl>.
Hi Martijn,
Nice excercise. As a user of Wicket, I'd say:
> Which one gets precedent? The modifier or onComponentTag?
either modifier or neither (an exception).
The modifier is added later and provides a one-time way to adapt an
existing component.
Letting the component have precedence is weird because then the modifier
was added for nothing.
If it is not possible to make this consistent, it should not be allowed
(the exception).
If it is not possible to check the consistency, the whole model is wrong
so I do not believe that this is the case.
> Does it even matter?
yes and users will expect it to be consistent for eternity (I would).
> Is the order of execution something that needs to be documented as a
> fixed contract, don't we care, should we even care?
yes, no, yes.
I understand your reservation; there are many ways in which a small
misunderstandings of the user can lead to users. However, I feel
sometimes feel the same frustration as Eelco describes. It happens at
points where I want to combine some simple stuff (like 1 line in JSP)
where in Wicket I have to either copy a whole class from the core, or
add 3 behaviors each with their own custom anonymous model class (20
lines). Wicket is super duper excellent for combining larger things, but
it gets a bit cumbersome when you're trying to combine small things.
Besides, a fool will shoot himself in the foot eventually.
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Martijn Dashorst <ma...@gmail.com>.
Just as a mental exercise, what will happen when we have this:
<a href="" wicket:id="foo">foo</a>
new AjaxLink(this, "foo") {
@Override protected void onComponentTag(...) {
super.onComponentTag(...);
tag.put("onclick", "alert('foo1');");
}
}.add(new SimpleAttributeModifier("onclick", "alert('bar1');"));
Which one gets precedent? The modifier or onComponentTag? Does it even
matter? Is the order of execution something that needs to be
documented as a fixed contract, don't we care, should we even care?
Martijn
On 12/6/06, Eelco Hillenius <ee...@gmail.com> wrote:
> I think using final for the onComponentTag and onComponentTagBody
> methods have served their purposes fine during our wild two years of
> development, but our core components are now stable enough to not have
> to be worried about painting ourselves in the corner when we would
> open up these methods (ie remove final).
>
> Please vote:
> [ ] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> [ ] no, leave the code as it is now
>
> Eelco
>
--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>
Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Igor Vaynberg <ig...@gmail.com>.
the problem with opening up all of them is that it is not clear what the
methods do, or how to override them (call super, and if so first or last?)
if you look at a component - and imagine you have no source code - how do
you know what it does in oncomponent* methods? these are internal
implementation details that you are overriding.
so if we are going to open them up we need to update the javadoc to say what
exactly happens and how it should be overridden.
i kinda hate to say it but this is another place where annotations can be
useful just because of the programming model they introduce (listener
registration) for event handlers. i dont think we should reintroduce annots,
but maybe instead we might consider switching to listener registration even
though that introduces more state.
-igor
On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
>
> A lot of people have asked in the past for a component interface and
> we said no (until OSGi came with a good reason, and even then). Just
> only asking for opening up is not a good reason to do so IMO.
>
> A good reason I can come up with for removing final from the
> onComponentTag method is to reduce the need for AttributeModifiers.
> These use up memory just as components, and therefore can increase
> memory load. I have done so in a couple of places in our application,
> reducing the memory footprint considerably. However, these were done
> on Panels and WebMarkupContainers, which already don't have a final on
> onComponentTag.
>
> My point here is: removing final from onComponentTag may give better
> scalability, and in some cases even be more convenient (if you already
> are subclassing the component).
>
> I have yet to encounter a case for removing final from onComponentBody
> on all (or any for that matter) components. In my opinion removing
> final from onCB gives too much opportunity for servlet style
> programming.
>
> [-0.5] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> [0.5] no, leave the code as it is now
>
> Martijn
>
> --
> <a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
> for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> ">Wicket</a>
> at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> the World!</a>
>
Re: Re: Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Igor Vaynberg <ig...@gmail.com>.
and that can easily be expressed with a
+0 i dont like it but not enough to block
-igor
On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
>
> Just doing it as the manual says :) If you get 3 times -0.5 votes,
> that may be a strong indicator that it is not the way to go. IIUC part
> of voting is the ability to disagree, either mildly, strongly, or even
> unresolvable. This is reflected by the analog votes.
>
> In this case, I don't want to block a consensus on the proposal (if
> one is attained), but do think that the current situation serves us
> well. i.e. if everyone else agrees to remove final from these methods,
> I won't block it. That doesn't mean that I agree with the proposal,
> nor that I don't care. I care enough to say that I don't agree, but
> don't want to stop the show.
>
> Martijn
>
> On 12/7/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > that has got to be one of the most idiotic things i have ever seen.
> >
> > so what does this mean?
> >
> > +1 -0.5 -0.5 -0.5 ? does that mean the vote doesnt pass? cause when you
> add
> > them up you get a -0.5
> >
> > can i vote?
> > -
> >
> 0.333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
> >
> > -igor
> >
> >
> > On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> > >
> > > From:
> > >
> > > +0: 'I don't feel strongly about it, but I'm okey with this.'
> > > -0: 'I won't get in the way, but I'd rather we didn't do this.'
> > > -0.5: 'I don't like this idea, but I can't find any rational
> > > justification for my feelings.'
> > > ++1: 'Wow! I like this! Let's do it!'
> > > -0.9: 'I really don't like this, but I'm not going to stand in the way
> > > if everyone else wants to go ahead with it.'
> > > +0.9: 'This is a cool idea and i like it, but I don't have time/the
> > > skills necessary to help out.'
> > >
> > > [1] http://www.apache.org/foundation/voting.html#Veto
> > >
> > >
> > > On 12/7/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > wtf is a 0.5 vote? can i vote 0.7 for and 0.3 against? my brain cant
> do
> > > > floating point math!
> > > >
> > > > /me kicks martijn in the ball
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> > > > >
> > > > > A lot of people have asked in the past for a component interface
> and
> > > > > we said no (until OSGi came with a good reason, and even then).
> Just
> > > > > only asking for opening up is not a good reason to do so IMO.
> > > > >
> > > > > A good reason I can come up with for removing final from the
> > > > > onComponentTag method is to reduce the need for
> AttributeModifiers.
> > > > > These use up memory just as components, and therefore can increase
> > > > > memory load. I have done so in a couple of places in our
> application,
> > > > > reducing the memory footprint considerably. However, these were
> done
> > > > > on Panels and WebMarkupContainers, which already don't have a
> final on
> > > > > onComponentTag.
> > > > >
> > > > > My point here is: removing final from onComponentTag may give
> better
> > > > > scalability, and in some cases even be more convenient (if you
> already
> > > > > are subclassing the component).
> > > > >
> > > > > I have yet to encounter a case for removing final from
> onComponentBody
> > > > > on all (or any for that matter) components. In my opinion removing
> > > > > final from onCB gives too much opportunity for servlet style
> > > > > programming.
> > > > >
> > > > > [-0.5] yes, make all onComponentTag and onComponentTagBody methods
> of
> > > > > the standard components in core non-final. This does leave the
> door
> > > > > open for specific components to not adhere to that - I'm not
> proposing
> > > > > a new standard - but if this wins we would remove final for most
> of em
> > > > >
> > > > > [0.5] no, leave the code as it is now
> > > > >
> > > > > Martijn
> > > > >
> > > > > --
> > > > > <a href="http://www.thebeststuffintheworld.com/vote_for/wicket
> > > ">Vote</a>
> > > > > for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> > > > > ">Wicket</a>
> > > > > at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff
> in
> > > > > the World!</a>
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > <a href="http://www.thebeststuffintheworld.com/vote_for/wicket
> ">Vote</a>
> > > for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> > > ">Wicket</a>
> > > at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> > > the World!</a>
> > >
> >
> >
>
>
> --
> <a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
> for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> ">Wicket</a>
> at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> the World!</a>
>
Re: Re: Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Martijn Dashorst <ma...@gmail.com>.
Just doing it as the manual says :) If you get 3 times -0.5 votes,
that may be a strong indicator that it is not the way to go. IIUC part
of voting is the ability to disagree, either mildly, strongly, or even
unresolvable. This is reflected by the analog votes.
In this case, I don't want to block a consensus on the proposal (if
one is attained), but do think that the current situation serves us
well. i.e. if everyone else agrees to remove final from these methods,
I won't block it. That doesn't mean that I agree with the proposal,
nor that I don't care. I care enough to say that I don't agree, but
don't want to stop the show.
Martijn
On 12/7/06, Igor Vaynberg <ig...@gmail.com> wrote:
> that has got to be one of the most idiotic things i have ever seen.
>
> so what does this mean?
>
> +1 -0.5 -0.5 -0.5 ? does that mean the vote doesnt pass? cause when you add
> them up you get a -0.5
>
> can i vote?
> -
> 0.333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
>
> -igor
>
>
> On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> >
> > From:
> >
> > +0: 'I don't feel strongly about it, but I'm okey with this.'
> > -0: 'I won't get in the way, but I'd rather we didn't do this.'
> > -0.5: 'I don't like this idea, but I can't find any rational
> > justification for my feelings.'
> > ++1: 'Wow! I like this! Let's do it!'
> > -0.9: 'I really don't like this, but I'm not going to stand in the way
> > if everyone else wants to go ahead with it.'
> > +0.9: 'This is a cool idea and i like it, but I don't have time/the
> > skills necessary to help out.'
> >
> > [1] http://www.apache.org/foundation/voting.html#Veto
> >
> >
> > On 12/7/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > > wtf is a 0.5 vote? can i vote 0.7 for and 0.3 against? my brain cant do
> > > floating point math!
> > >
> > > /me kicks martijn in the ball
> > >
> > > -igor
> > >
> > >
> > > On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> > > >
> > > > A lot of people have asked in the past for a component interface and
> > > > we said no (until OSGi came with a good reason, and even then). Just
> > > > only asking for opening up is not a good reason to do so IMO.
> > > >
> > > > A good reason I can come up with for removing final from the
> > > > onComponentTag method is to reduce the need for AttributeModifiers.
> > > > These use up memory just as components, and therefore can increase
> > > > memory load. I have done so in a couple of places in our application,
> > > > reducing the memory footprint considerably. However, these were done
> > > > on Panels and WebMarkupContainers, which already don't have a final on
> > > > onComponentTag.
> > > >
> > > > My point here is: removing final from onComponentTag may give better
> > > > scalability, and in some cases even be more convenient (if you already
> > > > are subclassing the component).
> > > >
> > > > I have yet to encounter a case for removing final from onComponentBody
> > > > on all (or any for that matter) components. In my opinion removing
> > > > final from onCB gives too much opportunity for servlet style
> > > > programming.
> > > >
> > > > [-0.5] yes, make all onComponentTag and onComponentTagBody methods of
> > > > the standard components in core non-final. This does leave the door
> > > > open for specific components to not adhere to that - I'm not proposing
> > > > a new standard - but if this wins we would remove final for most of em
> > > >
> > > > [0.5] no, leave the code as it is now
> > > >
> > > > Martijn
> > > >
> > > > --
> > > > <a href="http://www.thebeststuffintheworld.com/vote_for/wicket
> > ">Vote</a>
> > > > for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> > > > ">Wicket</a>
> > > > at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> > > > the World!</a>
> > > >
> > >
> > >
> >
> >
> > --
> > <a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
> > for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> > ">Wicket</a>
> > at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> > the World!</a>
> >
>
>
--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>
Re: Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Igor Vaynberg <ig...@gmail.com>.
that has got to be one of the most idiotic things i have ever seen.
so what does this mean?
+1 -0.5 -0.5 -0.5 ? does that mean the vote doesnt pass? cause when you add
them up you get a -0.5
can i vote?
-
0.333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
-igor
On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
>
> From:
>
> +0: 'I don't feel strongly about it, but I'm okey with this.'
> -0: 'I won't get in the way, but I'd rather we didn't do this.'
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
> ++1: 'Wow! I like this! Let's do it!'
> -0.9: 'I really don't like this, but I'm not going to stand in the way
> if everyone else wants to go ahead with it.'
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> [1] http://www.apache.org/foundation/voting.html#Veto
>
>
> On 12/7/06, Igor Vaynberg <ig...@gmail.com> wrote:
> > wtf is a 0.5 vote? can i vote 0.7 for and 0.3 against? my brain cant do
> > floating point math!
> >
> > /me kicks martijn in the ball
> >
> > -igor
> >
> >
> > On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> > >
> > > A lot of people have asked in the past for a component interface and
> > > we said no (until OSGi came with a good reason, and even then). Just
> > > only asking for opening up is not a good reason to do so IMO.
> > >
> > > A good reason I can come up with for removing final from the
> > > onComponentTag method is to reduce the need for AttributeModifiers.
> > > These use up memory just as components, and therefore can increase
> > > memory load. I have done so in a couple of places in our application,
> > > reducing the memory footprint considerably. However, these were done
> > > on Panels and WebMarkupContainers, which already don't have a final on
> > > onComponentTag.
> > >
> > > My point here is: removing final from onComponentTag may give better
> > > scalability, and in some cases even be more convenient (if you already
> > > are subclassing the component).
> > >
> > > I have yet to encounter a case for removing final from onComponentBody
> > > on all (or any for that matter) components. In my opinion removing
> > > final from onCB gives too much opportunity for servlet style
> > > programming.
> > >
> > > [-0.5] yes, make all onComponentTag and onComponentTagBody methods of
> > > the standard components in core non-final. This does leave the door
> > > open for specific components to not adhere to that - I'm not proposing
> > > a new standard - but if this wins we would remove final for most of em
> > >
> > > [0.5] no, leave the code as it is now
> > >
> > > Martijn
> > >
> > > --
> > > <a href="http://www.thebeststuffintheworld.com/vote_for/wicket
> ">Vote</a>
> > > for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> > > ">Wicket</a>
> > > at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> > > the World!</a>
> > >
> >
> >
>
>
> --
> <a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
> for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> ">Wicket</a>
> at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> the World!</a>
>
Re: Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Martijn Dashorst <ma...@gmail.com>.
From:
+0: 'I don't feel strongly about it, but I'm okey with this.'
-0: 'I won't get in the way, but I'd rather we didn't do this.'
-0.5: 'I don't like this idea, but I can't find any rational
justification for my feelings.'
++1: 'Wow! I like this! Let's do it!'
-0.9: 'I really don't like this, but I'm not going to stand in the way
if everyone else wants to go ahead with it.'
+0.9: 'This is a cool idea and i like it, but I don't have time/the
skills necessary to help out.'
[1] http://www.apache.org/foundation/voting.html#Veto
On 12/7/06, Igor Vaynberg <ig...@gmail.com> wrote:
> wtf is a 0.5 vote? can i vote 0.7 for and 0.3 against? my brain cant do
> floating point math!
>
> /me kicks martijn in the ball
>
> -igor
>
>
> On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
> >
> > A lot of people have asked in the past for a component interface and
> > we said no (until OSGi came with a good reason, and even then). Just
> > only asking for opening up is not a good reason to do so IMO.
> >
> > A good reason I can come up with for removing final from the
> > onComponentTag method is to reduce the need for AttributeModifiers.
> > These use up memory just as components, and therefore can increase
> > memory load. I have done so in a couple of places in our application,
> > reducing the memory footprint considerably. However, these were done
> > on Panels and WebMarkupContainers, which already don't have a final on
> > onComponentTag.
> >
> > My point here is: removing final from onComponentTag may give better
> > scalability, and in some cases even be more convenient (if you already
> > are subclassing the component).
> >
> > I have yet to encounter a case for removing final from onComponentBody
> > on all (or any for that matter) components. In my opinion removing
> > final from onCB gives too much opportunity for servlet style
> > programming.
> >
> > [-0.5] yes, make all onComponentTag and onComponentTagBody methods of
> > the standard components in core non-final. This does leave the door
> > open for specific components to not adhere to that - I'm not proposing
> > a new standard - but if this wins we would remove final for most of em
> >
> > [0.5] no, leave the code as it is now
> >
> > Martijn
> >
> > --
> > <a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
> > for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> > ">Wicket</a>
> > at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> > the World!</a>
> >
>
>
--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>
Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Igor Vaynberg <ig...@gmail.com>.
lets Math.floor() martijn's vote :)
-igor
On 12/7/06, Johan Compagner <jc...@gmail.com> wrote:
>
> can i vote 0.7 for and 0.3 against? my brain cant do
> > floating point math!
>
>
>
> simple, thats 0.4 for it!
>
> :)
>
> johan
>
>
Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Johan Compagner <jc...@gmail.com>.
can i vote 0.7 for and 0.3 against? my brain cant do
> floating point math!
simple, thats 0.4 for it!
:)
johan
Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Igor Vaynberg <ig...@gmail.com>.
wtf is a 0.5 vote? can i vote 0.7 for and 0.3 against? my brain cant do
floating point math!
/me kicks martijn in the ball
-igor
On 12/7/06, Martijn Dashorst <ma...@gmail.com> wrote:
>
> A lot of people have asked in the past for a component interface and
> we said no (until OSGi came with a good reason, and even then). Just
> only asking for opening up is not a good reason to do so IMO.
>
> A good reason I can come up with for removing final from the
> onComponentTag method is to reduce the need for AttributeModifiers.
> These use up memory just as components, and therefore can increase
> memory load. I have done so in a couple of places in our application,
> reducing the memory footprint considerably. However, these were done
> on Panels and WebMarkupContainers, which already don't have a final on
> onComponentTag.
>
> My point here is: removing final from onComponentTag may give better
> scalability, and in some cases even be more convenient (if you already
> are subclassing the component).
>
> I have yet to encounter a case for removing final from onComponentBody
> on all (or any for that matter) components. In my opinion removing
> final from onCB gives too much opportunity for servlet style
> programming.
>
> [-0.5] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> [0.5] no, leave the code as it is now
>
> Martijn
>
> --
> <a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
> for <a href="http://www.thebeststuffintheworld.com/stuff/wicket
> ">Wicket</a>
> at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
> the World!</a>
>
Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Martijn Dashorst <ma...@gmail.com>.
A lot of people have asked in the past for a component interface and
we said no (until OSGi came with a good reason, and even then). Just
only asking for opening up is not a good reason to do so IMO.
A good reason I can come up with for removing final from the
onComponentTag method is to reduce the need for AttributeModifiers.
These use up memory just as components, and therefore can increase
memory load. I have done so in a couple of places in our application,
reducing the memory footprint considerably. However, these were done
on Panels and WebMarkupContainers, which already don't have a final on
onComponentTag.
My point here is: removing final from onComponentTag may give better
scalability, and in some cases even be more convenient (if you already
are subclassing the component).
I have yet to encounter a case for removing final from onComponentBody
on all (or any for that matter) components. In my opinion removing
final from onCB gives too much opportunity for servlet style
programming.
[-0.5] yes, make all onComponentTag and onComponentTagBody methods of
the standard components in core non-final. This does leave the door
open for specific components to not adhere to that - I'm not proposing
a new standard - but if this wins we would remove final for most of em
[0.5] no, leave the code as it is now
Martijn
--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
I'm not proposing to ease up on final in general, though I think using
finals aggressively makes more sense when the project is taking shape
and less so when things got more stabilized. Components like Link,
TextField, CheckBox, ImageButton are components people regularly ask
about why they can't override onComponentTag(Body) on the lists or on
IRC, and tbh I wouldn't know. People can mess up for sure, but otoh if
you're know what you're doing it makes perfect sense sometimes. There
are a lot of places where it is easy to come up with good arguments on
why you want to hide/ protect certain code, but onComponentTag(Body)
on most of our core components imho are not.
Eelco
On 12/6/06, Juergen Donnerstag <ju...@gmail.com> wrote:
> And what is the reason why you want to remove final? What are the use
> cases? I understand your words, but just removing final to remove
> final, IMO is not a good idea. I don't mind though to relax our
> general position on removing final for these two methods if there is
> real use case. I still think the fairly strikt approach we took at the
> beginning served us very well.
>
> Juergen
>
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Juergen Donnerstag <ju...@gmail.com>.
And what is the reason why you want to remove final? What are the use
cases? I understand your words, but just removing final to remove
final, IMO is not a good idea. I don't mind though to relax our
general position on removing final for these two methods if there is
real use case. I still think the fairly strikt approach we took at the
beginning served us very well.
Juergen
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Eelco Hillenius <ee...@gmail.com>.
> (These are open votes, right?)
Sure, all votes are welcome. But your vote is non-binding where
committers' votes are binding.
Eelco
Re: VOTE: make all onComponentTag and onComponentTagBody methods
non-final
Posted by Erik van Oosten <e....@chello.nl>.
[X] Yes
[ ] no
Yes! My first vote here :)
(These are open votes, right?)
Erik.
Eelco Hillenius wrote:
> I think using final for the onComponentTag and onComponentTagBody
> methods have served their purposes fine during our wild two years of
> development, but our core components are now stable enough to not have
> to be worried about painting ourselves in the corner when we would
> open up these methods (ie remove final).
>
> Please vote:
> [ ] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> [ ] no, leave the code as it is now
>
> Eelco
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Igor Vaynberg <ig...@gmail.com>.
+0
as i said, imho we need a better programming model
-igor
On 12/6/06, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I think using final for the onComponentTag and onComponentTagBody
> methods have served their purposes fine during our wild two years of
> development, but our core components are now stable enough to not have
> to be worried about painting ourselves in the corner when we would
> open up these methods (ie remove final).
>
> Please vote:
> [ ] yes, make all onComponentTag and onComponentTagBody methods of
> the standard components in core non-final. This does leave the door
> open for specific components to not adhere to that - I'm not proposing
> a new standard - but if this wins we would remove final for most of em
>
> [ ] no, leave the code as it is now
>
> Eelco
>
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
[ X ] yes, make all onComponentTag and onComponentTagBody methods of
the standard components in core non-final. This does leave the door
open for specific components to not adhere to that - I'm not proposing
a new standard - but if this wins we would remove final for most of em
[ ] no, leave the code as it is now
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/