-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluate Dropping @Provides #71
Comments
cc/ @swankjesse |
sgtm |
This is tough. What about methods like |
Yeah, for whatever reason, this one just makes me nervous. There's something about having to look up an annotation on an enclosing class to figure out what's going to happen that leaves me uneasy. Actually, as we introduce |
Supporting dual purpose modules wasn't something I thought about. Good |
I think |
With set and map declaration moving to its own annotation,
@Provides
can be argued as useless, redundant information. All non-private, non-static methods would become providers. Public methods on modules which are not providers seems like an anti-pattern or erroneous. This also brings a stronger corollary to components.I briefly discussed this with @gk5885 last week.
The text was updated successfully, but these errors were encountered: