Christian Edward Jackson-Gruber

Hmm. Other way around - Lazy requires Foo. Or rather, technically, it requires Provider. But from a sort of structural dependency, Lazy is a wrapper of foo, and providers are...

Oh no. ``` @Provide Foo provideFoo(Lazy lazy) { } ``` That should break, hard. That is a circular dependency, specifically, and should fail at compile time. If it doesn't, we...

So how about something like this: ``` digraph G1 { concentrate = false; n2 [label="A"]; n3 [label="B"]; n4 [label="C"]; n5 [label="D"]; n6 [label="E"]; n7 [label="F"]; n8 [label="G"]; n2 -> n3...

The linker is aggresively linking in the parent and does block until it's done. This is necessarily so in Dagger1 because there's no other way to figure out where an...

Oh - wait. we're making classes listed in injects= a provider? I don't think we do that - we create a deferredbinding for it, but I thought we need a...

As was mentioned, Dagger 2.x is on the http://github.com/google/dagger project. The square project is for Dagger 1.x

The short answer to why Dagger requires @Inject constructors is seen in simple errors like this: String. ``` class Foo { @Inject String string; } ``` If permitted non-@Inject-annotated constructors,...

Yeah - so that code seems like it should work. Why it would be trying to implicitly-bind something that has a provides method is very odd. I'll try to play...

It's not though, @JakeWharton. It seems like he's calling the constructor explicitly in an `@Provides` method. No? Or am I missing something obvious?

I'm sorry - I'm not following - what do you mean "AA" generated classes? On 4 September 2014 13:39, Eugene Beletskiy [email protected] wrote: > Bumped into the same issues with...