On Feb 28, 1:22 pm, bank kus <[email protected]> wrote:
> So the rationale behind not allowing child's couplings to override the
> parents coupling is:
> <a> to not become dependent upon the order of module placement in the
> injector's constructor arg list?
> OR
> <b> Simply avoid the feature to keep lookup simple.
We don't allow a child module to bind the same type as a parent module
to avoid surprises. This comes up with just-in-time bindings.
Consider:
public static void main(String[] args) {
Guice.createInjector(
new AbstractModule() {
public void configure() {
bind(Rug.class).to(Bearskin.class);
bind(Music.class).to(BarryWhite.class);
bind(Upholstery.class).to(ItalianLeather.class);
bind(Wood.class).to(ExpensiveMohogany.class);
}
},
new PrivateModule() {
public void configure() {
bind(Fireplace.class).to(WoodburningFireplace.class);
bind(Wood.class).to(CheapPine.class);
expose(Fireplace.class);
}
});
}
static class WoodburningFireplace implements Fireplace {
@Inject Wood wood;
public void burninate() {
wood.becomeAshes();
}
}
It will completely blow your mind, but when you run this code your
fireplace will totally burninate your expensive mohogany. The reason
is that although the binding for Fireplace.class lives in the private
module, the WoodburningFireplace gets a just-in-time binding.
So basically, we disallow duplicated bindings 'cause sometimes the we
don't you to get burned.
Cheers,
Jesse
PS - especially since the fire department's response time is worse
than this user's list!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
