Re-Binding

[Christopher Gammage]

Hi Guys,

Why does GIN not allow you to re-bind something?   

Here is a use case that I've had in the past.

I created a library with lots of MVP components in it.  I provided Modules for those components and allowed the user of the library to create

their own Ginjector and use my modules from my library.  What I wanted was for them to be able to extend or change the components in my library by

extending my modules and rebinding certain parts.  I still need to provide the default bindings since some users of the library may not want to change things.

This could be done at one level by @ImplementedBy because it allows you to rebind 1 time in your module.  This also does not work with bindings in factories though.

I can see how giving the warning in bind for rebinding makes sense, since someone may accidently do it., but what if there was a rebind method on the binder?

I guess this would break Guice compatability...

Any ideas? thoughts?

[Peter Schmitt]

Hi Christopher,

there is a good reason Guice doesn't allow this: It's already difficult enough to find the correct binding that creates a value injected somewhere entirely different in the code base. This opaqueness is a major reason why Guice is disliked by many. Having multiple possible bindings and having to figure out which one actually applies only makes the problem worse.

While I know that rebinding would be really nice in some cases, I don't think it is worth the extra cost. Instead I suggest you try to structure your code such that rebinding isn't necessary in the first place: Have small, contained modules that can easily be swapped out and only ever use install() at the top level (in Gin, for example, by never using it at all and instead configuring all modules on your Ginjector). In addition, if you're looking for a plugin mechanism, you could look at multibinders and see if they help in your situation.

Hope this helps!

Peter

--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-gin+...@googlegroups.com.
To post to this group, send email to googl...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-gin.
For more options, visit https://groups.google.com/d/optout.

[Goktug Gokdogan]

Actually this is supported by Guice[1] and could probably supported by GIN as well:

But as Peter pointed, it is always better to make designs that wouldn't require such overriding. For example, other than Multibindings you can also provide customization using polymorphism in modules:

class MyFrameworkModule extends AbstractGinModule {
  final void configure(..) {
    bindRootComponent();
  }

  protected void bindRootComponent() { 
     // bind the default root component
  }
}

class MyAppModukle extends AbstractGinModuke {
    // optionally overrides the method and binds something different for the root component
    protected void bindRootComponent() { 
     .....
    }
}

[1] http://google-guice.googlecode.com/git/javadoc/com/google/inject/util/Modules.html#override(com.google.inject.Module...)

[Christopher Gammage]

I didn't think to do this Goktug! It's a bit verbose, but it would work.  The module override would be another cool way of doing it, i'm guessing that's not on a todo list for GIN.  

[Goktug Gokdogan]

On Sat, May 17, 2014 at 11:27 PM, Christopher Gammage <gamm...@gmail.com> wrote:

I didn't think to do this Goktug! It's a bit verbose, but it would work.  The module override would be another cool way of doing it, i'm guessing that's not on a todo list for GIN.  

Actually it is but I'm not aware of anyone working on it:

https://code.google.com/p/google-gin/issues/detail?id=169