Hi Martin,
>1. I'd prefer if there are no more API changes until we start with 8.x.
sure, we can postpone the change to 8.x (if we agree to do it)
>2. Removing the generics here will introduce casting wherever
#convertToObject() is needed to be used.
>So we will move the problem to the callers
That's the point I was trying to make: There aren't many callers of that
method, mostly framework code only.
As a Wicket user I encounter the opposite regularly: overriding
#getConverter() to provide a custom converter.
Regards
Sven
Am 25.03.2015 um 18:04 schrieb Martin Grigorov:
Hi Sven,
1. I'd prefer if there are no more API changes until we start with 8.x.
2. Removing the generics here will introduce casting wherever
#convertToObject() is needed to be used. So we will move the problem to the
callers. I am not sure the benefit is big. But I may be wrong. I need to
see the diff of such change.
Martin Grigorov
Freelancer, available for hire!
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Mar 25, 2015 at 5:28 PM, Sven Meier <[email protected]> wrote:
Hi all,
currently IConverterLocator#getConverter() declares a generic parameter
<C>.
But very few places in Wicket call this method and even less benefit from
the generic return type.
Providing a custom converter for a component is rather clumsy:
public <C> IConverter<C> getConverter(Class<C> clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
@SuppressWarnings("unchecked")
IConverter<C> result = (IConverter<C>)converter;
return result;
}
else
{
return super.getConverter(clazz);
}
}
Note that this code doesn't benefit at all from the generic parameter,
even worse the converter has to be cast and the unchecked warning has to be
suppressed.
I propose to remove the generic parameter from the method, that would make
it easier for user code to override this method.
WDYT?
Have fun
Sven
