On 26/04/10 00:36, Sam Berlin wrote: > Folks, > > There's a lot of issues open right now that are never going to be > resolved because they go against the spirit / design philosophies of > Guice or are easily solvable using extensions or the SPI. Many of them > can be closed as "will not fix". Here's some issues which I think can > be closed as "will not fix", and why. I'll mark these as "will not fix" > next weekend -- if you don't think that's a good resolution, please pipe up!
Most of these I see the point of wontfixing. There is one, though, which I ask to be reconsidered: > http://code.google.com/p/google-guice/issues/detail?id=27 - Inject the > InjectionPoint > - Enables fragile code. Much of the desired effect can be implemented > by using the custom injections SPI anyway. > > http://code.google.com/p/google-guice/issues/detail?id=412 - > Context-sensitive Providers > - Similar to issue 27 & 49, and can be worked around using the custom > injections SPI. These are kind of the same issue, and whilst they can be *worked around*, it's not very elegant to do so - and you have to use a custom annotation, not @Inject, and you have to write manual java reflection code to actually perform the injection, instead of being able to leverage Guice. To take the example of loggers - at the moment, java.util.logging.Logger has a very special hardcoded binding in the core of Guice, and there is no way to give equivalent treatment to another logging framework via the Guice SPI. So long as the Guice SPI only offers partial workarounds, I do not think these should be wontfixed. I believe there is a valid use-case for InjectionPoint-aware Providers, and would like to see such a thing available in Guice. Thanks, Max.
signature.asc
Description: OpenPGP digital signature
