Also, were are the Dagger lists? I poked around a bit and couldn't find any. I had some random questions about why certain decisions were made in the design.
-- Brian On Apr 8, 2013, at 3:01 PM, Bob Lee <crazy...@crazybob.org> wrote: > I agree with Jesse. To improve maintainability, we need less dynamism, not > more, and more explicitness, not less. Silk looks like a step in the wrong > direction, while Dagger is a step in the right direction. > > Generally speaking, very little is actually subjective when it comes to > programming. One design is almost always objectively better or worse than > another. > > Let's move further Silk-related discussions to the Silk list. > > Bob > > > > On Sun, Apr 7, 2013 at 9:14 AM, je...@swank.ca <limpbiz...@gmail.com> wrote: > I don't fully agree on the criteria of this comparison. Jan, you and I > disagree on which DI features are useful and which ones are harmful! > > Having worked a some large Guice applications (dozens of modules) I think > Guice's biggest flaw is that it is very dynamic. Although this is essential > for building powerful frameworks, it also makes larger codebases more > difficult to navigate & understand. > > Silk is more dynamic than Guice. Features like loose multibinds, > mostPreciseOf() and TARGET_INSTANCE scare me just a little. The lack of > annotations means it's not obvious from the application code which classes > participate in dependency injection. I'd have to actually use Silk to learn > if this is a problem in practice. > > I've also been working on a Guice-like dependency injector called Dagger. Its > like a mini Guice, that intentionally omits dynamic bindings. I've filled out > how Dagger stands for the Guice-vs-the-World comparison here: > https://docs.google.com/spreadsheet/ccc?key=0AqH4uBT50p0tdEhLOEU1WHB4RUZjR2RURVF6MThkZnc#gid=0 > The Dagger column confirms that it does less than the other dependency > injectors. For me this is a feature, but it does limit the appeal of Dagger > for larger projects. > > And for larger projects is where the entire comparison itself starts to fall > down. > > When a developer chooses between Guice and Spring and the others, they're > less interested in features and more interested in the ecosystem. Spring has > a huge ecosystem and will integrate with everything. But I think Guice's > ecosystem is better still. It has first-party integration with JPA and > servlets. There's third-party integration for lots more, and it's possible > (if difficult) to write rich integrations for other infrastructure. > > Until Silk has an ecosystem like this around it, it's appeal for most > applications will be limited. > > > -- > 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 google-guice+unsubscr...@googlegroups.com. > To post to this group, send email to google-guice@googlegroups.com. > Visit this group at http://groups.google.com/group/google-guice?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > 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 google-guice+unsubscr...@googlegroups.com. > To post to this group, send email to google-guice@googlegroups.com. > Visit this group at http://groups.google.com/group/google-guice?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
