The example that continuously pops up in support of these issues is injecting a logger. Are there any other valid use-cases? Injecting a logger is very easily worked around by injecting a LoggerFactory that has a getLogger(Class) method that returns a logger. (And if LoggerFactory itself needs injected parameters, it can be bound using AssistedInject.) I suspect the same can be said for any other use-case (although I haven't seen other use-cases listed).
Ultimately, I believe the pain and degenerate code that can come from enabling such a feature seem to be far, far worse than the pain that comes from not having the feature. Sam On Mon, Apr 26, 2010 at 8:03 AM, Max Bowsher <[email protected]> wrote: > 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. > > > -- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
