Support more binding dimensions

[GoogleCodeExporter]

1. Right match injection points to bindings using only the exact type. If
type A extends B, we have a binding to A, and we need a B, we could use the
binding to A.

This would enable you to write:

  bind(FooImpl.class);

instead of:

  bind(Foo.class).to(FooImpl.class);

This could make debugging a little more difficult as it adds another
dimension of magic.

2. We could allow bindings to the same type and annotation within different
scopes. This would add yet another dimension to the search for a matching
binding. For example, you could do something like this:

  @Inject @SessionScoped User user;

Perhaps we should do away with the idea of a Key altogether. A binding
would consist of the type, annotation, scope, etc. We would index on all of
these attributes. Then we would search for a best match to a given
injection point.

This could get tricky very fast. Right now it's very easy for a user to
look at an injection point and then find the exact binding which matches it.

Original issue reported on code.google.com by crazybob...@gmail.com on 7 Mar 2007 at 10:30

[GoogleCodeExporter]

That should read, "right now, we match injection points to bindings using only 
the
exact type."

Original comment by crazybob...@gmail.com on 7 Mar 2007 at 10:32

[GoogleCodeExporter]

Maybe the module could ask for this:

  bindAllSuperTypes().to(FooImpl.class).

...but with a less ugly name.

But I could see this getting banned by some style guides for similar reasons as
wildcard imports.

Original comment by bslesinsky on 8 Jul 2007 at 12:32

[GoogleCodeExporter]

If the type hierarchy is this:
   class UserImpl implements User
   interface User implements Entity, Serializable, Identity
...it's very difficult to automagically decide which types UserImpl should 
satisfy. The best I can recommend is that 
users write their own utility methods. Perhaps one of these:
  bindImplementedInterfaces(UserImpl.class);
  link(UserImpl.class, User.class, Identity.class);

Original comment by limpbizkit on 30 May 2008 at 7:39

• Changed state: New
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

-1 for suggestion #1 
because of the mentioned complexity

+1 for suggestion #2
because it saves us from configuring a lot bindings. Even @SessionScoped might 
be a
binding and a scope annotation, you have to configure each bean for each scope 
in
order to archive differently scoped injections for the same bean type. The map 
of
scopeAnnotation->scope does already configured, so its "only" a matter of 
applying
the annotated scope of a dependency to it's binding's provider. Open questions: 
Is 
the currently configured scope for that binding replaced or is the configured 
scope
enclosed in the annotated one?

Original comment by sven.lin...@gmail.com on 16 Jun 2008 at 5:24

[GoogleCodeExporter]

Moves Guice a bit too far into the classpath-scanning land.  It would be pretty 
easy
for an extension to support this, by including some kind of new 
bindAllSupertypes()
method and scanning the classpath for supertypes.  If folks sufficiently want 
it,
that extension will pop up and be used.

Original comment by sberlin on 2 May 2010 at 12:52

• Changed state: WontFix