Yeah, I'd try the atinject list & if it gets no response, try the
individual lists.  Hopefully it won't be too controversial a question.

 sam


On Tue, Apr 8, 2014 at 11:26 AM, Tavian Barnes <[email protected]> wrote:

> On Monday, 7 April 2014 17:47:48 UTC-4, Sam Berlin wrote:
>>
>> I'd be open to any of the following:
>>   a) Hard-error on a qualifer/bindingannotation on types
>>   b) Support qualifer/bindingannotation on types, but fail if it also
>> exists on the variable
>>
>
> Makes sense. I do think one of them should be done before Guice 4.0 is out
> since that'll be the first release supporting Java 8 anyway. I'll try to
> cook up a patch for (a) and then (b) on top of it.
>
>
>> Though, since this'd be a change to the way jsr330 things are
>> interpreted, seems like it'd be best to poll the jsr330 folks and make sure
>> all various implementations (Dagger, Spring, etc..) are on-board with the
>> same solution.
>>
>
> Good point. The atinject list seems dead though, should I post there or
> manually poll Dagger, Spring, HK2, CDI, etc.?
>
>
>>  sam
>>
>>
>> On Mon, Apr 7, 2014 at 5:24 PM, Tavian Barnes <[email protected]> wrote:
>>
>>> Java 8 allows annotations to appear everywhere a type is used, which
>>> allows for things like
>>>
>>> Provider<@Named("name") Thing> provider;
>>>
>>> instead of
>>>
>>> @Named("name") Provider<Thing> provider;
>>>
>>> The first way, to me, seems more semantically accurate, because it reads
>>> "provider of named thing" rather than "named provider of thing." However,
>>> there would obviously be a lot of complication in choosing to support this
>>> syntax.  It would be difficult to use the new AnnotatedType reflection APIs
>>> and still support Java 6/7.  Ambiguous cases like
>>>
>>> @Named("name") Provider<@Named("otherName") Thing> provider;
>>>
>>> would have to be detected too.  Of the three choices:
>>>
>>> (1) Ignore binding annotations on types
>>> (2) Support binding annotations on types
>>> (3) Give a warning/error for binding annotations on types,
>>>
>>> I assume Guice is sticking with (1) for now?  If someone wrote a
>>> patchset to support AnnotatedTypes in a backwards-compatible way (strategy
>>> pattern for example), would (2), (3), or neither be most likely to get
>>> merged?
>>>
>>> --
>>> 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.

Reply via email to