On Thursday, August 21, 2014 8:43:18 AM UTC+2, Jochen Wiedmann wrote:
>
> I'm not sure, whether I get you right. But to me this sounds like a 
> situation where I would create child injectors and somehow make sure that 
> they are accessible. For example, in a web application, I might create a 
> parent injector for the whole web application. And, for any HTTP Request, I 
> might create a child injector with request specific data (a database 
> transaction comes to mind) and store that in a ThreadLocal.
>
> OTOH, my example might interfere a lot with scopes. But, to be honest: I 
> never really understood what scopes are good for.
>

Scopes would be a good fit when child injectors don't work. E.g. you have 
some object that's a singleton or quasi-singleton (because reasons; part of 
a framework for instance) but needs access to objects with a shorter 
lifetime (things that would otherwise belong to a child injector in your 
book, but that would be impossible here); in that case, the singleton 
object can be injected a Provider<OtherObject>. When it knows it needs to 
reuse the same OtherObject instance, it makes it so that it calls 
Provider#get once only; when it doesn't care whether it's the same instance 
as before, it calls Provider#get; and whether it gets the same instance or 
another one is not its responsibility.

Also, "child injectors" are not part of JSR330 whereas scopes are, so 
scopes are more "portable" than child injectors, and classes can elect to 
be used in some scopes by being annotated themselves whereas with child 
injectors you'd rely on the wiring of the injectors and not messing things 
up.

(note: Dagger uses child injectors to implement scopes; AFAICT it forbids 
mixing scopes with a Provider<> but that's generally thought of as a bad 
practice anyway, AFAIK)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-guice/72516ad2-dc71-4b73-81c7-b99cc01bd585%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to