From dhanji on March 22, 2007 01:09:37

good idea. if it has a single argument can u also provide the "injectee"?

From tpeierls on March 22, 2007 04:27:06

There's a trade-off between reducing dependency on c.g.i and preserving
comprehension. As with @Inject in issue 70 , the word Provider is a big hint about
what's going on. Take them away and it's that much harder to understand the code at a
glance.

From dhanji on March 22, 2007 08:05:48

Tim, you would annotate those methods as @ProviderMethod. I dont think the argument
is to magic away dependency on guice, rather to add support for arbitrary "factory"
style methods (as was discussed on the list I believe).

From kevinb9n on April 20, 2007 08:43:24

Dhanji, that's a good idea, I think.

Some examples:

  @ProviderMethod
  public [static] MyThing provideMyThing() { ... }

  @ProviderMethod
  public [static] MyOtherThing provideMyOtherThing(InjectionPoint ip) { ... }

  @ProviderMethod @MyBindingAnnotation(foo = 3) @RequestScoped
  public [static] MyOtherThing provideWhatever() { ... }

Then you would just need to, in your Module,

  bindStaticProviderMethods(ThatClass.class);
or
  bindProviderMethods(ThatClass.class);

depending on whether the methods are static or not; in the first case it just looks
right on that exact class, while in the second case it uses the normal resolution
scheme to obtain an instance of ThatClass, then checks every annotated
@ProviderMethod on ThatClass itself (probably omitting @ProviderMethods that are in
the concrete type of the resolved instance but not in the ThatClass interface, I
suppose).

And you can name the methods anything you want and no one cares.

Can anyone tear this proposal apart?

From zorzella on April 20, 2007 09:10:44

We likes it, my preciousssss.

From mcculls on May 30, 2007 21:04:12

Really like ProviderMethods in trunk - saved me from writing lots of scaffolding :)

However did run into problems with generic provider methods, for example:

    public abstract class FooProvider<T>
    {
        @Provides
        public T provideFoo(...blah...)
        {
            ...blah...
        }
    }

coz the erased return type of the declared method ends up as java.lang.Object :(

Use case: want to 'provide' utility class for people to use which contains a binding
pattern, but don't know what types will use it in advance (hence use of generics).
Tried generic providers, but got very messy - much cleaner with ProviderMethods.

So I hacked up a quick patch (see attachment) to handle generic return types which
requires the generic provider to be subclassed just like in TypeLiteral, for example:

    install( ProviderMethods.from( new FooProvider<MyConcreteClass>() {} ) );

This works great for the simple case above, but not for more complex return types
like Iterable<T> or more complex generic classes. However it would be nice to see
simple generic return types supported in trunk using something like this patch ;)

Hope this helps!

Attachment: gist
   GenericProviderMethods.patch

From crazyboblee on September 09, 2007 14:10:51

Sorry about that, mcculls. I just noticed this problem myself while do warning cleaup
ad fixed it to support generic types.

From limpbizkit on June 08, 2008 22:42:35

This needs test coverage before it can be closed.

Labels: Milestone-Release2.0

From limpbizkit on July 14, 2008 10:25:44

Users have requested that AbstractModule automatically installs itself as a ProviderMethodsModule.

From limpbizkit on August 02, 2008 12:12:04

Generic types are now supported correctly. I used our new TypeResolver classto do this properly. http://publicobject.com/2008/07/typeresolver-tells-you-what-listget.html The only outstanding question - should AbstractModule automatically install itself as a ProviderMethodsModule?
If we do, we need to override equals() and hashCode() on the ProviderMethodsModule.

From limpbizkit on August 02, 2008 16:02:28

I changed it so that Binder automatically installs provider methods from ALL modules, not just abstract
modules. I figured it would be weird if changing from Module to AbstractModule changed the behaviour more
dramatically.

I also added doc to Module describing this change.

The only outstanding question - should we continue to support ProviderMethods.from() for non-module
instances? As far as I'm concerned, the utility of it is now significantly diminished. With Modules supported,
we could drop the ProviderMethods public class altogether.

Status: Fixed
Owner: limpbizkit