Dagger: Combine @BindsInstance & @IntoSet

Created on 24 Mar 2018  Â·  10Comments  Â·  Source: google/dagger

I have some custom initialization code to be run at a well-defined time. The code is passed to a Component from the outside via @BindsInstance. I'd like to do the following:

@BindsInstance Builder foo(@IntoSet Runnable initCode);

This does not compile due to @IntoSet. @ElementsIntoSet has the same issue. Would it be possible to support this pattern?

There are other Runnable pieces of initialization code within the Component that are in this same set, but I also need to pass in this one piece of external code.

Right now I pass the code in via another binding, and use a separate @Provides @IntoSet method in a module to funnel it into the set. Would be nice to do it directly.

P3 dagger feature request

Most helpful comment

I don't see a compelling reason not to allow this. This seems reasonable to me. I can look into what it would look like to add support for this but I imagine it wouldn't be so hard.

All 10 comments

@IntoSet targets methods. Did you try putting it on the method?

I didn't think that would work, but I'll try it out and report back once I can build again at the end of my big refactor. Thanks.

error: Multibinding annotations may only be on @Provides, @Produces, or @Binds methods

I don't see a compelling reason not to allow this. This seems reasonable to me. I can look into what it would look like to add support for this but I imagine it wouldn't be so hard.

Discussed this with @netdpb and he agrees. We'll get this prioritized

Two thoughts on this FR: would the methods be mandatory to call? And if so, could they be repeatable?

@ronshapiro because it is a set I would in general expect calling @BindsInstance @IntoSet methods to not be mandatory yet repeatable. I would find it unexpected and an obstacle, in general, to only allow calling that kind of method once.

The case for non-mandatory & repeatable @ElementsIntoSet is less strong, but because it is non-mandatory & repeatable inside a component I'd again expect the same behavior in a @BindsInstance context.

I think if a need became apparent to constrain these sets it should be handled via another mechanism. I would opt for generality to start out, as opposed to constraining the default behavior without a really compelling reason.

For my particular use case (initialization code):

  1. The component owner should be allowed to contribute initialization code or not; one owner may have a need to add specific initialization code, but another may not.
  2. The component owner should be allowed to contribute several pieces of initialization code. The component owner may itself receive initialization code from different places.

I'd like to use @BindsInstance together with @IntoSet too and see that the issue is still open (also tried it with the latest release); Is this feature currently planned and if so, when is it likely to be releaed?

Also, is there a workaround that comes to mind for the mean time? I'd like to contribute a set with an undefined number of services to the component, each service instance extending from a common supertype.

I think as a workaround you'd just define a module that has an instance @Provides @ElementsIntoSet method that returns the set of values you want contributed to the set, and provide your own way of building an instance of that module such that it returns the set of elements you want. Then you'd create an instance of the module and set it when creating the component.

Thank you! That should work fine for now.

On Wed, Mar 20, 2019 at 20:04, Colin Decker notifications@github.com wrote:
I think as a workaround you'd just define a module that has an instance @Provides @ElementsIntoSet method that returns the set of values you want contributed to the set, and provide your own way of building an instance of that module such that it returns the set of elements you want. Then you'd create that an instance of the module and set it when creating the component.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub [https://github.com/google/dagger/issues/1112#issuecomment-474985867] , or mute the thread [https://github.com/notifications/unsubscribe-auth/ABM44Ydb36lykje-MJ76CDSbK-9eUNsNks5vYoZEgaJpZM4S56lj] .

Was this page helpful?
0 / 5 - 0 ratings