ValueProvider ugly cast

[eguardiola]

It is possible to avoid the ugly ValueProvider cast ? TreeStore ModelKeyProvider is ok but the other... :-(

http://pastebin.com/eri7Prkc

[icfantv]

All the generics in 3.x do make things a little more tricky. Are you getting a compiler error or is your IDE complaining about the line if you don't have the cast?

[eguardiola]

Its just a compiler warning. The TreeStore constructor has <? super M> to allow supertypes for ModelKeyProvider but the Tree constructor does not allow the same for ValueProvider. I think that is the reason i have to put a ugly cast. Is it planned to refactor ValueProvider declarations to allow supertypes in the same way TreeStore and ListStore allow for ModelKeyProvider ?

public TreeStore(ModelKeyProvider<? super M> keyProvider)

public Tree(TreeStore<M> store, ValueProvider<M, C> valueProvider)

[icfantv]

I assume the warning is about an unchecked cast?

I created a subclass of Tree that modified the constructor argument to ValueProvider<? super M, C> and everything is happy except for the call to super(...) which expects M and not a parent.

I agree this seems like an oversight considering TreeStore has the <? super M> signature but admit I don't know the ramifications of changing this.

As I do not work for Sencha I cannot speak to the refactoring of the ValueProvider parameter. I would suggest and encourage you to file a bug in the bug forum with a title of something like "Inconsistent constructor signature between TreeStore and Tree" and then go into detail with your example (and solution).

HTH.

--adam

[Colin Alworth]

Many places that accept ValueProvider<T,V> can usually accept ValueProvider<? super T, V> - I have a patch that changes this in many places, but I've had concerns about committing it for the sake of readability, and for actually testing each and every case to be sure it can cause no other issues. As this has an (admittedly ugly) work around, this is a cleanup issue that has been ignored while harder to work around issues are attended to.

If I may ask, how are you creating these that you want the superclass of the model? PropertyAccess types can be made generic as of beta3, letting you define subtypes that make that type concrete. This doesn't completely deal with the issue, but in many cases it can prevent those ugly casts.

[eguardiola]

Thx Collin. I'm having the same problems with ComboBox LabelProvider not accepting supertypes.

In the first post you have a link to the example code im having problems with.

[Colin Alworth]

Thanks for the feedback everyone, in the 3.0.0 RC (www.sencha.com/products/extgwt/download) we just put up for download, you should see generics changes to deal with these kinds of cases - nearly all cases where ValueProvider<M,V>, or LabelProvider<M> is accepted, we've changed it to ValueProvider<? super M, V> and LabelProvider<? super M>. This hurt readability slightly, but makes it flexible to accept any kind of generated provider.

Please update this thread if you find cases I've missed or want to discuss other generics issues.

[eguardiola]

Many thanks Colin for commit this refactor. The application code now is more clean.