Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support more binding dimensions #55

Closed
gissuebot opened this issue Jul 7, 2014 · 5 comments
Closed

Support more binding dimensions #55

gissuebot opened this issue Jul 7, 2014 · 5 comments

Comments

@gissuebot
Copy link

From crazyboblee on March 07, 2007 17:30:57

  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.

  1. 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: http://code.google.com/p/google-guice/issues/detail?id=55

@gissuebot
Copy link
Author

From crazyboblee on March 07, 2007 14:32:03

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

@gissuebot
Copy link
Author

From bslesinsky on July 07, 2007 17:32:00

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.

@gissuebot
Copy link
Author

From limpbizkit on May 30, 2008 00:39:03

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);

Status: New
Labels: -Priority-Medium Priority-Low

@gissuebot
Copy link
Author

From sven.linstaedt on June 16, 2008 10:24:05

-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?

@gissuebot
Copy link
Author

From sberlin on May 02, 2010 05:52:17

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.

Status: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant