My only suggestion is to add a comment to each issue explaining why it won't be fixed, perhaps with a suggested alternate approach or link to something in the docs.
On Sun, Apr 25, 2010 at 6:36 PM, Sam Berlin <[email protected]> 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! > > 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]<google-guice-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-guice-dev?hl=en. > -- Eric M. Burke http://www.linkedin.com/in/ericburke 314-494-3185 (mobile) 636-294-0191 (home) -- 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.
