I see it as a pretty major api break. Considering that everyone on our project uses the construct to return quickly to the previous page, which is a very valid usecase. I can only imagine that many others have used this construct as well.
I *really* think that removing *existing* api because it /can/ be used incorrectly instead of educating through documentation is not the way to go. I am also against renaming it, again because the API break is significant. I also don't see a problem with deprecating the constructor and or class, and removing it in 1.4: this gives our projects, and those of our users with *LEGITIMATE* uses of it, the chance to migrate. It will also give users with wrong uses the message that they are using it wrong and a chance to do somethign about it at a moment that is convenient for them. As for 2.0 I don't mind removing it as the API is already much different (due to the constructor change). Deprecation is there for a reason: API migrations. I think we have a valid usecase here and should use that instead of blatently removing any constructor/class that is/may be widely used. As for the veto, I think we all have a right to disagree here: that is what I'm doing. Since when is rubber stamping proposals 'the Apache way'? Martijn On 2/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Very convenient to hold a vote when I'm not around... It wasn't concluded yet. And the vote wasn't started because of your absence, but because of a message to the list. Martijn, the tricky situation here is that everyone on the team - and I'm pretty sure incluI sading the ones who didn't vote - is very much against having this constructor. VERY much. It leads to a dangerous situation and as a message earlier this week showed, people ARE using it the wrong way. God knows how many. This is not just a matter of not reading the docs for people, this is a matter of the API guiding in the wrong direction. Also, if documentation was enough, why think about API design in the first place? Also, comparing with methods that have the 'do not use this' warnings in them is just plain bs, as we have such 'constructs' because there was alternative to them, mainly because Java doesn't have a friends construction. > -1 on removing the constructor. Just as Jonathan... Great, another veto. Jonathan was against removing the class altogether (which I am personally +1 for, but not that strongly to make a lot of trouble). He stated he uses the IPageLink constructor a lot, while this vote is for removing the Page constructor. The only alternative I can see here is to leave the constructor in - a half baked solution which I would hate nevertheless - but put a @deprecated tag with a big fat warning in it. Regards, Eelco
-- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
