Comments (10)
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.
from dagger.
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.
from dagger.
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 [email protected]:
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
.
from dagger.
@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.
from dagger.
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?
from dagger.
@JakeWharton currently that gives you an error, which is the right behavior in my opinion.
from dagger.
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!
from dagger.
Where did we land with this?
from dagger.
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.
from dagger.
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.
from dagger.
Related Issues (20)
- java.lang.NoClassDefFoundError: dagger.internal.Preconditions HOT 2
- java.lang.NoClassDefFoundError: dagger.internal.Preconditions HOT 1
- android.app.Application does not implement dagger.android.HasActivityInjector HOT 3
- --
- Android Context HOT 1
- Subcomponent inside subcomponent HOT 1
- Error when a component is trying to include bindings with different scopes could be more informative HOT 1
- Constructor injection cannot find symbol method inject members dagger2 2.14 HOT 1
- how can i run the example of CoffeeApp.java HOT 1
- Why do Singletons need an empty default constructor? HOT 2
- dagger-compiler
- dagger.android.DispatchingAndroidInjector cannot be provided without an @Provides HOT 1
- 每次修改完java代码都需要clean项目 才能运行, HOT 1
- did u consider this kind of case: ChildFragment needs to reuse ParentFragment's object instead of creating a new one。hilt may not support this kind of case
- duplicate Nullable HOT 2
- cannot generate
- Support extending base builder classes HOT 2
- The Hilt Android Gradle plugin is applied but no com.google.dagger:hilt-android dependency was found. HOT 1
- Issue with enableAggregatingTask flag / AGP 7.0 / oss-licenses HOT 1
- after add hilt { enableAggregatingTask = true } dependencies tasks faild
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dagger.