Evaluate Dropping @Provides

[JakeWharton]

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.

[JakeWharton]

cc/ @swankjesse

[codefromthecrypt]

sgtm

[swankjesse]

This is tough. What about methods like equals() and toString() ? What about configure() when a module simultaneously supports Dagger & Guice?

[gk5885]

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 @Provides/@Produces it might get a bit worse too…

[codefromthecrypt]

Supporting dual purpose modules wasn't something I thought about. Good
point.

[JakeWharton]

I think @Provides/@Produces seals it for me. Just wanted to have the discussion.