Add implementations of component default methods. about dagger HOT 6 CLOSED

Or, alternatively, outright forbid them.

from dagger.

I haven't even tried ‡ with Java 8. Right now does it not provide an implementation?

As far as the example goes, I don't think there's actually any issue with it in particular. Marking the component as @Singleton just says that it may contain singleton bindings. If you have a default method that returns a new TwitterApi per invocation, that's just like having a @Provides method that wasn't singleton in that component. I suppose you could mark that method @Singleton, but that would be super confusing I would think… we'd have to do something like ensure that bindings in the modules match the binding on the method or something. Ick.

Anyway, I'm tempted to just forbid them because I can't think of a reason that you'd actually want to do this. The problem is that I'm not sure that there's a good/clean way to do that in a processor that works under 1.7.

from dagger.

Right. The generated implementation does not include an override nor does it seem to include it in validation checking. I don't even know what the least-astonishing behavior would be here...

Not sure there's any real value in having default methods on components. Presumably it's the same value as having them on normal interfaces: evolution without changing downstream consumers. I'm just trying to break things before the masses get their hands on this.

I think you'd have to .name() the Modifier and do a string comparison in order to check in a compatible way if you did want to reject them outright.

from dagger.

I feel like the fact that we generate implementations means that a primary use case of default methods is sort of N/A anyway.

from dagger.

I'm marking this as a 2.1 release issue to resolve Java 8 default method behavior. In the mean-time it's specifically undefined behavior.

from dagger.

Why wouldn't we treat default methods on @Component interfaces just like concrete methods on @Component classes? That is, don't override them because they're not abstract.

In your example @JakeWharton, I don't see why you would expect two calls to api() to return the same thing. You've provided OKHttpClient as a @Singleton, not TwitterApi. Even if you meant to provide TwitterApi as a @Singleton, the api() method doesn't read to me as a component provision method, because it's not abstract.

from dagger.