It will? Smart. Maybe it *is* possible to thread it through then, somehow. Looks like this can get confusing real quickly... some experiments seem in order.
sam On Fri, Apr 11, 2014 at 12:50 PM, Tavian Barnes <[email protected]>wrote: > The Lazy example isn't related, I was just talking about the current > process of resolving type parameters in just-in-time bindings. The current > behaviour will give Lazy a Provider<String> for that example. > > On Friday, 11 April 2014 09:03:06 UTC-4, Sam Berlin wrote: > >> I love the annotation idea -- that would be a much simpler way using >> annotations with parameters, without requiring the user to make an >> implementation of it. >> >> The "Lazy" one doesn't really follow from it, though. "T" in Provider<T> >> would still be lost by erasure. You'd need to subclass Lazy in order to >> store the information in the type system. >> >> sam >> >> >> >> On Thu, Apr 10, 2014 at 10:19 PM, Tavian Barnes <[email protected]>wrote: >> >>> Something cool just occurred to me, it'd be nice to be able to write new >>> Key<@Named("foo") String>(){}. >>> >> >>> Anyway I think type annotations need a little more thought. If >>> Provider<@Named("foo") >>> String> works, why not this: >>> >>> // Attempt to simulate Dagger's Lazy<T> >>> public class Lazy<T> { >>> @Inject Provider<T> provider; >>> private T instance; >>> public synchronized T get() { >>> if (instance == null) instance = provider.get(); >>> return instance; >>> } >>> } >>> >>> public class Foo { >>> @Inject Lazy<@Named("foo") String> lazy; >>> } >>> >>> Does the @Named("foo") follow the type parameter into the >>> implementation of Lazy? If not, then I guess any binding annotations >>> on type arguments should cause an error unless they're on the argument to a >>> Provider. >>> >>> >>> On Tuesday, 8 April 2014 17:06:05 UTC-4, Christian Gruber wrote: >>> >>>> Heh. I just made an issue for exactly that purpose. >>>> >>>> c. >>>> >>>> On 8 Apr 2014, at 13:57, Tavian Barnes wrote: >>>> >>>> > What about tests? It seems difficult to test something like this >>>> > without >>>> > some test classes that actually use type annotations somewhere. >>>> > >>>> > Right now my idea is to put Java 8 specific tests in a special >>>> > package, and >>>> > exclude that package unless a special Maven profile is activated. I >>>> > assume >>>> > something equivalent is possible with Ant. >>>> > >>>> > On Tuesday, 8 April 2014 12:55:56 UTC-4, Sam Berlin wrote: >>>> > [snip] >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "google-guice" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at http://groups.google.com/group/google-guice. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-guice. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/d/optout.
