@Module(entrypoints=) either needs a rename or better documentation. about dagger HOT 12 CLOSED

I like graph roots but I don't love the word root because it's technically inconsistent.

A tree is called a rooted tree if one vertex has been designated the root, in which case the edges have a natural orientation, towards or away from the root. [...]

In Dagger, any node in the graph can be an entry point.

from dagger.

I thought about this today too, same concerns. What about injectPoints? This would align with callers of the inject() method.

from dagger.

Injection points are already defined to be the members with @Inject annotations.

from dagger.

Hmm I see... perhaps injectors would be more concise. I'm somewhat surprised that these objects can't be gathered at compile time. Perhaps it's for flexibility, to avoid a static annotation such as @Injector on the class, however, I could see myself using @Injector on all my classes that need to inject.

from dagger.

I've had to explain it quite a few times as well and I don't think the name is the sticking point so much as the concept. The name seems completely appropriate, I'd just recommend adding a few more examples to the docs and coming up with a more concise explanation (easier said than done, of course).

I've found that people pick the concept up quickest when I explain that an entry point is any class that makes explicit use of the ObjectGraph to be created or injected into (so that it's dependency tree can be validated). Simplified, it's any type that is passed into an .inject or .create call.

from dagger.

Patrick Baumann wrote:

I've found that people pick the concept up quickest when I explain
that an entry point is any class that makes explicit use of the
ObjectGraph to be created or injected into (so that it's dependency
tree can be validated). Simplified, it's any type that is passed into
an .inject or .create call.

Did you mean .inject(Object) or .get(Class<?>)?

from dagger.

Heh, yes. My bad. Shows how rarely I use it in my code base.

from dagger.

graphNodes?

from dagger.

I don't think graphNodes covers the current behavior because every dependency in a node in the graph.

It may help to consider the definition & purpose of entry point. An entry point is a type that is a legal argument to ObjectGraph.get() or ObjectGraph.inject(). We require these to be explicitly registered so that the entire graph can be known statically; otherwise types defined in @Provides modules is known statically but other types need to be created at runtime. Like Guice's JIT bindings.

Even if a node is not a graph root, we require an entry point for it if it's used in the two methods because otherwise code changes will have non-local effects. Removing a dependency may implicitly drop a node or series of nodes from the graph.

One other word that comes to mind is bootstrap. That's because the process of requesting injection from the object graph is a form of bootstrapping the application. For Android apps we need to do this in every module, but for most applications it should only happen in the main class.

from dagger.

I might call it "injects=..." The doc is "explicitly declares types this
module is capable of injecting."

Bob
On Mar 26, 2013 9:06 PM, "Jesse Wilson" [email protected] wrote:

I don't think graphNodes covers the current behavior because every
dependency in a node in the graph.

It may help to consider the definition & purpose of entry point. An entry
point is a type that is a legal argument to ObjectGraph.get() or
ObjectGraph.inject(). We require these to be explicitly registered so
that the entire graph can be known statically; otherwise types defined in
@provides modules is known statically but other types need to be created
at runtime. Like Guice's JIT bindings.

Even if a node is not a graph root, we require an entry point for it if
it's used in the two methods because otherwise code changes will have
non-local effects. Removing a dependency may implicitly drop a node or
series of nodes from the graph.

One other word that comes to mind is bootstrap. That's because the
process of requesting injection from the object graph is a form of
bootstrapping the application. For Android apps we need to do this in every
module, but for most applications it should only happen in the main class.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/154#issuecomment-15503308
.

from dagger.

+1 to Bob's suggestion. Let's do that.

from dagger.

#221

from dagger.