A few comments (also you should format your response in emails better. It was really hard to read):
>> 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 > If you inject a field directly you can't work without DI or reflection or the > field is public and mutable. Both I consider to be bad for keeping things > clean and predictable. I see field injection as a start of not treating > design smaller deficits that quickly outgrow a easy to repair situation. If I understand correctly what you are saying, this isn't true. You can inject private fields. > >> 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 > Well.. it is a grey-area for me. I don't see good reasons to favour it above > a field that is a application singleton that is injected. If things are > static they are static - means always what they are. Applying DI breaks this > contract. Maybe you have a example where it appear more valid ? I have used static injection a number of times to propagate decencies into frameworks that don't have access to the Injector. >> Why do you have Guice's AOP as red? This seems like it should be "green" to >> me. > Real aspects are hard to understand, debug and maintain. Therefore... I disagree. Intercepting in general isn't hard to understand and aspects aren't either. Plus, Guice uses annotations to declare them and document the methods that are being intercepted, therefore it is easy to understand. >> 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). > It means we actually speak about something declarative in a functional sense. > Hence there is no sequence dependency. > As guice is used with control flow code in modules it can't be truly > declarative. Not sure: What happens when you do linked bindings where target > is unbound ? If I understand what you are saying, Guice doesn't have problems if you have a link that hasn't been bound yet. >> 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 know that one would pop up. This deserves a own page in the docs. For now > let me say two points shortly: > 1) Overrides require a combined view to see/understand the result. You can > think of multiple layers with holes in them. To see what layer becomes > visible when they lay above each other you need to watch at all of them. This > is not the case for uninstall. When calling uninstall it will be uninstalled. > I do not have to know or look at other modules. Just the single on I > uninstall. This is much easier to compose (hence maintain) and understand. > 2) Overrides cascade the conflict resolution to the parent (the root in the > end). But the parent should or cannot know its children and grandchildren. > Resolving in this direction breaks the independence of smaller units and is > not combinable. E.g. a parent can't resolve conflicts for 2 variations that > again conflict in their resolution. Uninstall does not cascade upwards. It > keeps the conflict resolution locally in a sub-tree. I don't see a use case for uninstall and overrides have always worked well for me. I also use NoOp implementations instead of removing the binding because removing can cause major graph problems. >> 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. > First you need to give arguments why singletons (and we speak about context > singletons) are so extremely dangerous. This would take a blog post or something to fully cover. There are also many posts out in the world that cover the issues with singletons. Put simply, at any point you if you have a singleton, everything above it must be a singleton (you can't inject a singleton with an instance). I inject JDBC Connections into my services and unless they are a rats nest of proxies, singletons don't play nicely with short lived objects like Connections, EntityManagers, etc. >> 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. > listed! > > Performance is a tricky thing to measure. I didn't have time to do proper > tests. Let me say this: there are about 130 tests each creating a injector > context. All run in less than 200ms. That is less than 2ms per injector > context. Of cause these test create minimal test scenarios but I think purely > from the way it work I can say that it is very fast. I hope you mean it takes 2ms to create the injector (this still seems slow to me) and not to inject. Here's some examples from CleanSpeak, our full graph (50-100 objects) is all injection scoped and our requests complete in < 1ms. We also do around 25,000 requests per second, which means that Guice is creating 1250,000-250,000 objects each second. Also, the time it takes to create the Injector shouldn't really be a factor, but the faster you can make it the better. But this isn't what matters when it comes to picking a technology. Overall, it sounds like Silk isn't quite there yet with performance, but you certainly should do some testing where you use Silk to create and inject a graph that contains 100 injection scoped objects. Run that 10,000,000 and calculate the average, mean, min and max. Then do the same thing in Spring, Guice and Pico and see how you compare. -- Brian -- 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.
