Module overrides + multibindings = pain

[swankjesse]

Currently the overriding module replaces instead of adds to the set of multibindings. We should make a behavior-breaking-change and combine 'em all.

[cgruber]

I'm not opposed - we're early enough to break things… the principle at
stake here is the principle of least surprise. My main concern is that
overrides seems to be something that does replace, not contribute
additions, in the way we've used it. Swap-in new stuff for testing.
But multi binders are inherently a contributive/additive API. What
would be the least surprising interpretation for users?

Truthfully, this early, I'm ok for either - and if we want stronger,
non-testing use-cases for overrides then we need to consider that too.
Though if we go there, then we need to summit a bit and flesh out our
"strong module contract" idea that we whiteboarded and try to make it
strong enough because I think module overrides are a sort of weak flavor
of that.

[adennie]

My 2 cents: I think override should replace, not expand multibindings, both to accomodate the test replacement use case, and for consistency with single bindings.

[jclouds]

I'm currently using additive feature of multibindings to allow users to add
to a set of authentication providers.

-A

On Fri, Mar 8, 2013 at 5:35 PM, Andy Dennie notifications@github.comwrote:

My 2 cents: I think override should replace, not expand multibindings,
both to accomodate the test replacement use case, and for consistency with
single bindings.

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

[adennie]

@swankjesse @jclouds just to clarify my earlier comment, I acknowledge the use case for additive bindings, but "override" doesn't seem to me like the right vehicle for it.

[JakeWharton]

I'm actually opposed to this (despite being the person the current impl bit pretty hard). I think our failure is that we are using overrides = true carelessly when we should be using a child graph in this case. It wouldn't have solved the problem, but it would have made it much more clear.

Do we even know if set bindings and child graphs behave properly?

class Module1 {
  @Provides(type = SET) String a() { return "a"; }
  @Provides(type = SET) String b() { return "b"; }
}
class Module2 {
  @Provides(type = SET) String c() { return "c"; }
}

What does a graph with module 1 plussed to module 2 get me?

[swankjesse]

@JakeWharton currently that gives you an error, which is the right behavior in my opinion.

[arichiardi]

I follow you guys because this is really interesting. I agree with the override behavior of just replacing stuff (where this means replacing just dependencies or branches depending on the implementation). The adding behavior, for testing or not, is already in the Module composition. New module, new branch. Raising an exception if there are conflicts like above. IHMO (as always) and not knowing much about the current implementation :) Thanks!

[cgruber]

Where did we land with this?

[codefromthecrypt]

jeez this one's a tough call. I need to play with SET_VALUES in 1.1 more as this was the only place I needed overrides=true on set bindings before.

[JakeWharton]

Unless we find a really compelling reason to change, my vote is to do nothing. It behaves as expected when you think about it. It just surprised me when I ran into it.