Well that's why bob invented providers ;) Dhanji
On Monday, February 1, 2010, chris_l <[email protected]> wrote: > On Jan 26, 7:01 pm, Bob Lee <[email protected]> wrote: >> An XML config wouldn't add any value, so no one has bothered to implement >> it > > I also don't believe that an XML configuration is a very good > solution. But I don't agree that it wouldn't add any value. > > (1) XML would make it possible to generate a graph or do some modeling > even before the first line of code has been written. This doesn't > matter to me - for me the grapher in Guice is more than good enough. > But for a team with people that aren't willing to learn Java (but > still believe they can wire a system up front) it could be an > advantage. Ok, that's theoretical. But how about this: > > (2) This is based on the "Robot legs problem" (http://code.google.com/ > docreader/#p=google-guice&s=google-guice&t=FrequentlyAskedQuestions): > How to inject different things into the same point. > > public Leg(Foot foot) { ... } > > To get a different foot for the left and right leg you'll need private > modules, as is described in the FAQ. While private modules are very > powerful, I'd argue that the XML solution is a lot easier to read > here. But ok, it's a workable solution. However, what about recursive > structures? Let's make a simple, rather synthetic example first: Try > modeling the expression "3 * 4 * 7" according to this simple spec: > > Expr = Literal | Literal * Expr > > If you bind Literal to "3", you'll get the expression "3 * 3 * 3 > * ...". You can't arrive at "3 * 4 * 7", no matter which binding > annotations (Qualifiers) you use. I also don't see a solution with > private modules for this (correct me if I'm wrong). > In contrast, a structure like this is not only possible, but also > fairly easy to read with XML, schematically: > > <expr> > <literal value="3"/> > <expr> > <literal value="4"/> > <expr> > <literal value="5"/> > </expr> > </expr> > </expr> > > I'm afraid that such recursive structures can actually appear in real > life examples, where wiring with dependency injection makes sense: > Imagine you write a system that manages a network of routers. Each > router can be connected to a set of other routers... > > So while (1) is not a problem for me, I'm still afraid that (2) might > bite me someday. Don't get me wrong, I strongly prefer the Guice > approach over the XML approach, but I can imagine situations where it > won't work. The good news is, that this doesn't create a dead-end, > because Guice allows me to fall back to manual wiring for the > problematic object and encapsulate it in a provider. > > Chris > > -- > 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. > > -- 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.
