On Tue, Jun 30, 2009 at 11:04 AM, Erik van Oosten<[email protected]> wrote: > 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.
Right, I think your assumption is flawed. You can't be sure that nobody is using it. There could be some crazy framework code out there that relies on that. Having a warning in the 1.4 code (we're fudging things a bit here by deprecating in the 1.4 version, since it's only supposed to be about generification) is not a big deal, IMHO. > > 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. >
