Hi Brian, thanks for the good feedback. You really look into it. A general note: I know that I have quite extreme view points when it comes to harmful concepts but they are the result of mistakes I see being made and the reason to build something different like Silk. Therefore I have to value what I designed it to fix. Of cause I need to explain my thought and show why I see thinks as being better. It is purely a matter of time to write all this.
On 05.04.2013 20:19, Brian Pontarelli wrote: > > * 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. > listed. You can do such things but than you need to write your own Supplier class. I work on a more general feature to make such customisation even easier. > > * 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 > listed. Providers are a feature to pick. Interceptors just via services. > > * 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. > > * I like your Type interface. Cool. > Thanks. > > * Random thought, but I would consider changing your package names > to com.silkdi > Maybe at some point. > > * 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 ? > > * 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 guess I'm unclear about how "programmatic" interceptors are > different than aspects. Your Services documentation isn't done > yet, so this is pretty unclear. > The difference is - they are usual code. Visible in existence, debuggable as usual and simpler to understand as it is just code (as usual) and thereby better to maintain. But I need to extend the docs. You need to be a bit patient. > > * 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 ? > > * 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 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. > > * Why do you feel that Silk's lack of "Cycle" error reporting as an > improvement (marked as Green)? > It was maybe misleading. It does not allow dependency cycles and I think this is the only healthy way to build applications. Therefore 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. > 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'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. Great! > > -- 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.
