You know, since I made this thread I've changed my mind, I think
requireAtInjectOnConstructors() is perfect the way it is, and Guice
probably shouldn't add any more complexity around it.
But I agree that sometimes it's nice to have a weaker requirement. For
example, when shipping a library, I'd like to make sure that all my
library's injected classes have @Inject on their constructors, but not
require that for consumers of my library. This is a case where requiring
@Inject annotations only in a particular package (and maybe its
subpackages) would be nice.
Luckily you can do this yourself, either with a TypeListener or
Elements.getElements().
On Thursday, 25 February 2016 20:42:10 UTC-5, Geoff Groos wrote:
>
> I'd like to bump this but with package names rather than visibility
> restrictions.
>
> I too have data models that I don't want to be constructed by giuce, since
> they should almost always be used with @Assisted factory methods bound
> toInstance, but I would really like it if utility classes, (in particular
> and in my case, javafx.stage.DirectoryChooser, a class with an
> unannotated no-arg ctor) could be wired up automatically.
>
> We use requreAtInjectOnConstructors universally since it completely
> avoids a whole class of bugs around bad-binding of data objects. Right now
> I'm debating making a change toward more IOC with a utility class that
> wraps the Directory chooser (along with a couple other things). I would
> really like the issue to be as simple as "inject the DirectoryChooser, add
> tests to cover currently untested code, devs are happy", but it isn't that
> simple because I'd have to go off to a number of modules and update their
> configuration to
> bind(DirectoryChooser.class).toProvider(DirectoryChooser::new). I don't
> want to make those changes.
>
> An elegant solution to our problem would be to change the requireAtInject
> to support a package prefix:
> requireAtInjectonConstructors("com.mycompany"), which would require that
> everything in a package starting with "com.mycompany" uses the annotations,
> and everything in other packages (eg javafx.whatever) does not.
>
> Of course, this would change guice's own model from using a single boolean
> flag to using a set of filters, which is obviously substantially more
> complex.
>
> My .02, thanks for reading
>
> -Geoff
>
> On Friday, December 27, 2013 at 6:47:54 PM UTC-8, Tavian Barnes wrote:
>>
>> Okay good points, I guess I'll just bite the bullet and add them. It's
>> not too bad anyway, since I'd end up adding constructors to those classes
>> if they ever gained a dependency anyway. No reason to special-case
>> package-private classes with no dependencies just to save three lines of
>> code each.
>
>
--
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 https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/1224a651-4525-4ddd-a819-d3d847584082%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
