Have there been any updates on this in the past four years? Judging from 
the documentation and from an experiment I just ran, it looks like the 
answer is now. It seems desirable to me for Guice to use type annotations 
to distinguish keys for all the reasons mentioned early on in this thread.

On Monday, April 14, 2014 at 12:02:39 PM UTC-6, Tavian Barnes wrote:
>
> It looks like there are bugs in the current release's handling of 
> AnnotatedTypes that prevents this idea from working: 
> https://bugs.openjdk.java.net/browse/JDK-8039916.  That prevents the 
> annotation on Provider<@Named("foo") String> from being retrieved on a 
> constructor or method parameter; it only works on fields right now.  I 
> don't think it affects the new Key<@Named("foo") String>(){} idea at 
> least so I'll try to write that part.
>
> I asked this SO question about the bug: 
> http://stackoverflow.com/questions/23025363/how-to-get-generic-type-information-from-getannotatedparametertypes-in-java-8/23066816.
>  
>  Hopefully there's a workaround.
>
> On Friday, 11 April 2014 12:53:24 UTC-4, Sam Berlin wrote:
>>
>> 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 https://groups.google.com/group/google-guice.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-guice/e77e2fa5-5ce8-4183-8eca-d117ce9a68a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to