Should IStringResourceLoader#loadStringResource(Class,String,Locale,String) exist?

[Erik van Oosten]

Hi,

I am writing a custom IStringResourceLoader and noticed that
IStringResourceLoader#loadStringResource(Class,String,Locale,String) is not
called from anywhere except from within the implementations themselves.

Shall we remove the method from the interface, or did I miss other uses?

Regards,
    Erik.

--
Erik van Oosten
http://day-to-day-stuff.blogspot.com

[James Carman-3]

It's part of a public interface.  You can't just remove it.  Maybe the
internal Wicket code doesn't use it, but that doesn't mean that
someone else doesn't.  Where are you thinking of removing it from?  A
1.4-rcx or 1.5?  I'd say you probably need to deprecate it before you
remove it.

On Tue, Jun 30, 2009 at 6:58 AM, Erik van Oosten<e.vanoosten@...> wrote:

>
> Hi,
>
> I am writing a custom IStringResourceLoader and noticed that
> IStringResourceLoader#loadStringResource(Class,String,Locale,String) is not
> called from anywhere except from within the implementations themselves.
>
> Shall we remove the method from the interface, or did I miss other uses?
>
> Regards,
>    Erik.
>
> --
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com
>
>

[Erik van Oosten]

Yes, I understand that. However, as you typically register an
implementation of IStringResourceLoader in the Application's init. It
functions therefore only as a callback mechanism for Wicket itself. At
least, that is how I read the intent of the code.

Now I understand you are able to request the list of IStringResourceLoaders
yourself and then to clever things with them. So my question actually comes
down to: do we want to maintain the interface for a method that is not
needed for Wicket itself? (Or are there plans to use it from within
Wicket?)

The deprecation route does not work. Current implementation are rightly
using this method and should not get warnings because of that.

Regards,
    Erik.


On Tue, 30 Jun 2009 08:04:07 -0400, James Carman
<jcarman@...> wrote:

> It's part of a public interface.  You can't just remove it.  Maybe the
> internal Wicket code doesn't use it, but that doesn't mean that
> someone else doesn't.  Where are you thinking of removing it from?  A
> 1.4-rcx or 1.5?  I'd say you probably need to deprecate it before you
> remove it.
>
> On Tue, Jun 30, 2009 at 6:58 AM, Erik van Oosten<e.vanoosten@...>
> wrote:
>>
>> Hi,
>>
>> I am writing a custom IStringResourceLoader and noticed that
>> IStringResourceLoader#loadStringResource(Class,String,Locale,String) is
>> not
>> called from anywhere except from within the implementations themselves.
>>
>> Shall we remove the method from the interface, or did I miss other uses?
>>
>> Regards,
>>    Erik.
>>
>> --
>> Erik van Oosten
>> http://day-to-day-stuff.blogspot.com
>>
>>

[James Carman-3]

On Tue, Jun 30, 2009 at 8:32 AM, Erik van Oosten<e.vanoosten@...> wrote:
> The deprecation route does not work. Current implementation are rightly
> using this method and should not get warnings because of that.

So how were you going to remove it?

[Erik van Oosten]

I am only talking about the declaration on the interface.

Regards,
   Erik.


On Tue, 30 Jun 2009 08:42:51 -0400, James Carman
<jcarman@...> wrote:
> On Tue, Jun 30, 2009 at 8:32 AM, Erik van Oosten<e.vanoosten@...>
> wrote:
>> The deprecation route does not work. Current implementation are rightly
>> using this method and should not get warnings because of that.
>
> So how were you going to remove it?

[James Carman-3]

On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oosten<e.vanoosten@...> wrote:
>
> I am only talking about the declaration on the interface.

So, if deprecating the method on the interface would cause compiler
warnings, then removing the method on the interface would cause
compiler errors.  Right?

[Erik van Oosten]

No, no warnings, the method is only referred from classes that implement
the interface and therefore continue to work after the declaration has been
removed from the interface. Those classes might have an {@InheritDoc} on
the method in question, but that's easy to fix.

    Erik.


On Tue, 30 Jun 2009 08:54:20 -0400, James Carman
<jcarman@...> wrote:
> On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oosten<e.vanoosten@...>
> wrote:
>>
>> I am only talking about the declaration on the interface.
>
> So, if deprecating the method on the interface would cause compiler
> warnings, then removing the method on the interface would cause
> compiler errors.  Right?

[Martijn Dashorst]

Except when you use @override annotation.


On Tuesday, June 30, 2009, Erik van Oosten <e.vanoosten@...> wrote:

>
> No, no warnings, the method is only referred from classes that implement
> the interface and therefore continue to work after the declaration has been
> removed from the interface. Those classes might have an {@InheritDoc} on
> the method in question, but that's easy to fix.
>
>     Erik.
>
>
> On Tue, 30 Jun 2009 08:54:20 -0400, James Carman
> <jcarman@...> wrote:
>> On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oosten<e.vanoosten@...>
>> wrote:
>>>
>>> I am only talking about the declaration on the interface.
>>
>> So, if deprecating the method on the interface would cause compiler
>> warnings, then removing the method on the interface would cause
>> compiler errors.  Right?
>

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

[Erik van Oosten]

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?

Regards,
    Erik.


On Tue, 30 Jun 2009 15:03:31 +0200, Martijn Dashorst
<martijn.dashorst@...> wrote:

> Except when you use @override annotation.
>
>
> On Tuesday, June 30, 2009, Erik van Oosten <e.vanoosten@...> wrote:
>>
>> No, no warnings, the method is only referred from classes that implement
>> the interface and therefore continue to work after the declaration has
>> been
>> removed from the interface. Those classes might have an {@InheritDoc} on
>> the method in question, but that's easy to fix.
>>
>>     Erik.
>>
>>
>> On Tue, 30 Jun 2009 08:54:20 -0400, James Carman
>> <jcarman@...> wrote:
>>> On Tue, Jun 30, 2009 at 8:50 AM, Erik van Oosten<e.vanoosten@...>
>>> wrote:
>>>>
>>>> I am only talking about the declaration on the interface.
>>>
>>> So, if deprecating the method on the interface would cause compiler
>>> warnings, then removing the method on the interface would cause
>>> compiler errors.  Right?
>>

[James Carman-3]

On Tue, Jun 30, 2009 at 9:21 AM, Erik van Oosten<e.vanoosten@...> 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.

[Erik van Oosten]

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
<jcarman@...> wrote:

> On Tue, Jun 30, 2009 at 9:21 AM, Erik van Oosten<e.vanoosten@...>
> 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.

[James Carman-3]

On Tue, Jun 30, 2009 at 11:04 AM, Erik van Oosten<e.vanoosten@...> 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
> <jcarman@...> wrote:
>> On Tue, Jun 30, 2009 at 9:21 AM, Erik van Oosten<e.vanoosten@...>
>> 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.
>

[Juergen Donnerstag]

IStringResourceLoader#loadStringResource(Class,String,Locale,String)
exists by purpose since we can not gurantee that we always have a
Component (the other method of the interface). Via this interface you
may look up the property for every class.

Juergen