Perhaps if circular dependencies are disabled, then a new @AllowCircular annotation can be added to explicitly enable circular dependencies (on certain parameters) so that they can be allowed on a case-by-case basis. As much as I dislike circular dependencies, sometimes they're incredibly hard to fix properly.
Sam On Thu, Mar 19, 2009 at 8:32 PM, Bob Lee <[email protected]> wrote: > I assume you're talking about circular deps between constructors. This is a > tough problem. Injecting proxies was an experiment that I don't really like > to advertise. We can't just keep injecting new instances because we'd go > into an infinite loop. In the long run, I think the best solution will be to > generate an error when we encounter a circular dep. The solution to the > error will be to inject a Provider<X> into one of the constructors or to > move the dep into an injected method instead (not currently supported). > > Bob > > On Thu, Mar 19, 2009 at 5:18 PM, Jonathan <[email protected]> wrote: >> >> Looking over the way Guice handles circular dependencies, it looks >> like the resulting object for some expected type is inserted into each >> of the delegating proxies that were created as a result of a circular >> dependency. I know this is just one solution to a nasty problem, but I >> was hoping to find that each of the circular dependencies would get >> their own instance of the expected type. Is this possible? >> >> Regards - >> jonathan >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
