Initial comments and thoughts: You should be more specific about post-construction injection as a "feature" and compare each framework on it. I would guess that most projects require this at some point and since Silk doesn't support it, it impacts the current usability of Silk in some projects. I didn't look through the documentation completely, but do you support injecting Providers and Aspects (interceptors)? This would be something to cover in your matrix I disagree that field injection is "considered harmful" in all cases. Setter injection I agree with, but not always field injection (privates and finals). Therefore, your "green" square doesn't always apply I like your Type interface. Cool. Random thought, but I would consider changing your package names to com.silkdi I disagree that static injection is always harmful and in some cases it is required. Not supporting it is not as "green" as you are implying Why do you have Guice's AOP as red? This seems like it should be "green" to me. I guess I'm unclear about how "programmatic" interceptors are different than aspects. Your Services documentation isn't done yet, so this is pretty unclear. I'm unclear what "Sequence of Declarations" means for modularity. Guice doesn't require bindings to be ordered (as far as I know) and I don't think module ordering matters unless you have duplicate bindings (which should be prevented for all DI frameworks). I'm not a huge fan of always putting Guice and Spring concepts in Red or Yellow and yours in Green. For example, why is Module overrides in Red and Install/Uninstall in Green. I view these as different and not better or worse. I would argue that using Singleton as your default scope is EXTREMELY DANGEROUS and would put Silk's in Red. In fact, I would argue that using Singleton at all can be dangerous. Singletons can infest your application and cause major problems. You should consider using injection scope as the default. Why do you feel that Silk's lack of "Cycle" error reporting as an improvement (marked as Green)? You need to include performance in your matrix. One of the main reasons I use Guice is for performance and it is vital to me. If Silk is faster, great! But if it is slower, it would be a deal breaker.
I'll continue to check out as your documentation comes along and might play around with Silk to get a better idea of how you have improved on DI. It is good to see people working to improve on DI. -- Brian On Apr 4, 2013, at 1:07 AM, Jan Bernitt <[email protected]> wrote: > Hi, > > I made a comparison http://www.silkdi.com/help/comparison.html page comparing > my DI tool to other frameworks and guice is one of them. > > Please let me know if I got something wrong (in the guice column) or you have > additional or yet missing information I could add to make it more complete. > Any other feedback is of cause also welcome. > > Jan > > -- > 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?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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
