You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Various framework code based on Guice needs to bind a parameterized type where some of the type arguments contain in-scope type variables, which obviously must be reified by existing type tokens of some kind. A contrived example:
TypeLiteral<List<T>> tl_LT = new TypeLiteral<List<T>>() {};
but there is no way to pass in classT, so Guice will inevitably raise the error "List<T> cannot be used as a key; It is not fully specified" when it discovers the information is missing. The following works, but is clunky and incurs an unchecked warning:
The implementation then reads the anonymous subclass's extends declaration "TypeLiteralV1<List<T>, T>" to learn that T is reified by tl_T, and thus uses tl_T to construct a reification of List of whatever T actually is.
I have sample code for this construction from a Google internal project, and the code has just been approved for open-source release. I will be submitting a patch based on this code to Guice.
Yes this would be a very nice thing to have. I am running into the exact same problem and need to do an ugly cast to get things going. Is there any reason against this?
From mattmccutchen@google.com on September 30, 2011 18:37:49
Various framework code based on Guice needs to bind a parameterized type where some of the type arguments contain in-scope type variables, which obviously must be reified by existing type tokens of some kind. A contrived example:
abstract class FancyModule extends AbstractModule {
<T> AnnotatedBindingBuilder<List<T>> bindListOf(Class<T> classT) {
TypeLiteral<List<T>> tl_LT = /* ??? */;
return bind(tl_LT);
}
}
One would like to just do:
TypeLiteral<List<T>> tl_LT = new TypeLiteral<List<T>>() {};
but there is no way to pass in classT, so Guice will inevitably raise the error "List<T> cannot be used as a key; It is not fully specified" when it discovers the information is missing. The following works, but is clunky and incurs an unchecked warning:
TypeLiteral<List<T>> tl_LT = (TypeLiteral<List<T>>)
TypeLiteral.get(Types.newParameterizedType(List.class, classT));
I propose to introduce new variants of the TypeLiteral class that take additional type parameters and corresponding TypeLiteral tokens, like this:
abstract class TypeLiteralV1<T, A> extends TypeLiteral<T> {
protected TypeLiteralV1(TypeLiteral<A> tokA) { ... }
}
TypeLiteral<T> tl_T = TypeLiteral.get(classT);
TypeLiteral<List<T>> tl_LT = new TypeLiteralV1<List<T>, T>(tlT) {};
The implementation then reads the anonymous subclass's extends declaration "TypeLiteralV1<List<T>, T>" to learn that T is reified by tl_T, and thus uses tl_T to construct a reification of List of whatever T actually is.
I have sample code for this construction from a Google internal project, and the code has just been approved for open-source release. I will be submitting a patch based on this code to Guice.
Original issue: http://code.google.com/p/google-guice/issues/detail?id=657
The text was updated successfully, but these errors were encountered: