Right, now we are indeed discussing the main point: are there any clients
that are using this method via the interface?
In case there /are/ clients using this method, then we are basically
screwed. You can deprecate the method, but that will (temporarily) hurt the
implementations of the interface with warnings. (You also require people to
implement the full interface even though you know the method will go.) When
the method is really gone, you break backward/forward compatibility of
libraries (between version that is common for Wicket anyway).
Let us assume for a moment /no/ clients are using this method though the
interface. In this case it makes no sense to deprecate the method. We
simply remove the method declaration and fix @Override and {...@inheritdoc}
annotations in the Wicket code base.
I think the assumption is fair. Currently the interface exists solely to
let Wicket do string resource lookups. (Wicket itself does not refer to the
method via the interface.)
Anyway, from what I read in your last e-mail I think you /are/ assuming
there are clients outside of Wicket. So I guess nothing will change.
Regards,
Erik.
On Tue, 30 Jun 2009 09:52:00 -0400, James Carman
<[email protected]> wrote:
> On Tue, Jun 30, 2009 at 9:21 AM, Erik van Oosten<[email protected]>
> wrote:
>>
>> Correct. So its not a thing to do for 1.4 as you will have a compile
>> error
>> iff you use @Override.
>>
>> Can we go back to main point now?
>
> We are discussing the main point. You're proposing removing a method
> from an interface in the Wicket API without deprecating it first. I'd
> vote for deprecation. If there is any client code out there that uses
> the method, then they'll be notified via the deprecation. You have an
> opportunity with 1.4 to deprecate it if you want. Then, remove it for
> 1.5.
