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!
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=49 - Allow user-provided "autobinders" - Similiar to issue 27, likely solvable by the custom injections SPI also. http://code.google.com/p/google-guice/issues/detail?id=55 - Support more binding dimensions - Not implemented so far for a reason -- it moves Guice a bit too far into the classpath-scanning direction. http://code.google.com/p/google-guice/issues/detail?id=58 - Translate error messages - Just not worth it IMO. I can't think of any other tool (short of the JDK itself, and only in some places) that translates error messages / exceptions. And even then, the translations actually turn out to be more of a problem if you need to programmaticly parse them to figure out what's gone wrong. http://code.google.com/p/google-guice/issues/detail?id=96 - Decorators, that injection point can ask to have applied ad-hoc - Similiar to issues 27 & 49 insofar as "magic". Also it looks like an extension listed in the comments provides support for it anyway. http://code.google.com/p/google-guice/issues/detail?id=106 - make guice annotations a separate build artifact - Not worth it IMHO. Although, if we did support it then it should contain the guice analogue of the javax.inject classes. (That's not a bad idea, actually..) http://code.google.com/p/google-guice/issues/detail?id=118 - Get the class provided by a provider - I think this can be worked around using the SPI, and adding it into Guice core wouldn't really be possible (because technically a Provider can return any number of subclasses on different calls to get(). http://code.google.com/p/google-guice/issues/detail?id=136 - NPE when lazily using a scoped provider - No clue why issue is titled that, but that's not what it's about -- it's about telling Guice to internally proxy a binding to make it lazier. Easily doable with a custom provider (and in fact I've already written code that does this). http://code.google.com/p/google-guice/issues/detail?id=167 - Proxy-based interceptors (rather than subclass-based interceptors) - As mentioned in the comments, can be done with an extension and would be confusing in the core. http://code.google.com/p/google-guice/issues/detail?id=214 - Register additional scope and binding annotation during binding phase - I think this is resolvable using the existing SPI also (please correct me if I'm wrong, I'm less sure about this particular one). http://code.google.com/p/google-guice/issues/detail?id=400 - Pull out CGLib and reexport it in OSGi - Exposes an implementation detail that I don't think we want to expose. http://code.google.com/p/google-guice/issues/detail?id=406 - Shortcuts in configuration - Adds methods to the API that aren't necessary and can be done with 3rd party extensions. 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. http://code.google.com/p/google-guice/issues/detail?id=416 - Method interception on non-guice created objects - Not something that's going to go into Guice (based on reading other issues / threads). http://code.google.com/p/google-guice/issues/detail?id=419 - Another way to assist injections - Wants to change Injector.getInstance API to expose getInstance(clazz, varargs). http://code.google.com/p/google-guice/issues/detail?id=422 - Allow type inference in assisted injection - Wants to translate parameters (factory requests String, impl has @Assisted Integer). Unless we can somehow do this with the type conversion code... which admittedly I haven't thought through. http://code.google.com/p/google-guice/issues/detail?id=441 - Add annotations for AssistedInject factories - Promotes more use of @ImplementedBy and in general is syntactic sugar for stuff that's not hard to do right now. http://code.google.com/p/google-guice/issues/detail?id=467 - add a bindCollection(Class) to handle component oriented programming - Complicates the API for what looks like not so much gain. The goal is solvable with MapBinder or @Provides relatively easily, also. Sam -- 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.
