Interesting. What would prevent you from simply having those types
depend on those configuration values in their constructors. How are you
intending to inject them? Why are they not simply already part of your
graph?
Also, what do you mean by "atomic configuration values"? What renders
them different from any bound value of equal or wider scope?
c.
On 5 Apr 2014, at 11:47, Jochen Wiedmann wrote:
On Saturday, April 5, 2014 8:33:58 PM UTC+2, Christian Gruber wrote:
Guice will examine that implementation class, pick out its
constructor
with @Inject, and then analyze its dependencies. I think the
provider
wrapper is unnecessary.
True, but my intention is to have the provider do other stuff in the
future. (Like injecting atomic configuration values.)
Jochen
--
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.
Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: [email protected] :::: mobile: +1 (646) 807-9839
--
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.
