abstract provides methods

[codefromthecrypt]

This is probably more a usage question than an issue.

I've got something goofy in denominator wrt dagger. Basically a Provider (like route53) is a dagger module. I want to make it easy to implement and inject provider metadata without having to know too many details. For example, our DNSApiManager uses Provider (a dagger module) directly.

    @Inject
    DNSApiManager(Provider provider, DNSApi api, Closeable closer) {
        this.provider = provider;
        this.api = api;
        this.closer = closer;
    }

Provider defines some things like its name and the type of credentials it can accept as abstract methods. I'd prefer this to be an interface actually.

Anyway, these are needed pre-dagger, as that metadata is used to determine what other dagger modules are needed (chicken-egg problem).

ex. the module list for the graph includes the provider module, and conditionally other modules.
if (provider.defaultCredentialSupplier().isPresent()) { modulesForGraph.add(credentials(provider.defaultCredentialSupplier().get()));

I can't put @provides on on Provider as it is an abstract class, so I ask users to do something in their subclass which is smelly.

@Provides
Provider provideThis() {
   return this;
}

I'd like to eliminate the provideThis() and could if @Provides` abstract methods were somehow possible. Another way would be to refactor denominator to unwind this in some way I'm not aware of.

Thoughts?

[jclouds]

ahh.. maybe we can rename to DNSProvider :)

Anyway, that's a good idea, trying ObjectGraph.plus() will try it.

On Sat, Mar 2, 2013 at 9:00 AM, Jesse Wilson notifications@github.comwrote:

This is difficult to grok 'cause your Provider is different than
JSR-330's Providerhttps://code.google.com/p/atinject/source/browse/trunk/src/javax/inject/Provider.java
.

One thing you could experiment with is ObjectGraph.plus(). Perhaps you
could build your application in two phases: build a small inner object
graph with everything you need during bootstrap, then build upon that to
create a more complete object graph.

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

[cgruber]

The one thought I did have that's worth making is that I generally think
it's not the best idea to turn objects used in the graph into @ Modules
as well. That is entirely feasible because of the annotative-nature of
dagger's configuration, but I think it conflates objects - makes objects
have multiple purposes that can really lead to confusion. So.. not
forbidden, but certainly not my personal recommendation. (If I"m reading
your description right).

On 2 Mar 2013, at 8:27, Adrian Cole wrote:

This is probably more a usage question than an issue.

[JakeWharton]

Just a heads-up @adriancole, as you may have seen with #196 fixing #188 we now explicitly are disallowing inheritance in modules.

[codefromthecrypt]

Thanks for the heads up!

[JakeWharton]

Removing wont fix it since you are already subscribed to this issue. You can change your subscription preference by using the drop down at the bottom of the page. As you alluded, you were auto-subscribed when he didn't fence your name with backticks. It's hard to remember to do this 100% of the time.

[modules]

@JakeWharton thanks

[JakeWharton]

Closing this. It isn't really an issue but more of a discussion around best practices. The mailing list is a great place for this and probably will reach more users.