why not let us remove it, and you copy it into your project
-igor
On 2/25/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
i don't want to gang up on martijn here, but that's what i meant.
i also think we should refactor pagelink with the remaining two
constructors to:
pageclasslink (the one with the class contructor)
and
delayedpagelink (the one with the ipagelink constructor)
this way there is no class name pagelink (which is dangerous because
it's such an obvious name). this situation will make it very obvious
what users ought to do (now Link is the most obvious class) and
pageclasslink
and delayedpagelink will both be slightly more efficient since they won't
share an unused field. then users will have a choice between:
link
pageclasslink
bookmarkablepagelink
delayedpagelink
that seems like a very good situation.
if you're still unhappy, martijn, maybe we could keep the page constructor
in a deprecated class like pagereferencelink. that would help guide users
away from the class, but it would still be there for backwards compat.
jon
Eelco Hillenius 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 including 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
>
>
--
View this message in context:
http://www.nabble.com/VOTE%3A-remove-PageLink%28String%2CPage%29-constructor-tf3274259.html#a9145872
Sent from the Wicket - Dev mailing list archive at Nabble.com.
