Re: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
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
On 12/7/06, Eelco Hillenius [EMAIL PROTECTED] 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: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote: On 12/7/06, Eelco Hillenius [EMAIL PROTECTED] 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
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: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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.33 -igor On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
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 [EMAIL PROTECTED] 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.33 -igor On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.33 -igor On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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: Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] 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
