Support for Lazy<T> like Dagger

[tavianator]

I've implemented a version of Dagger's Lazy<T> in Sangria. But it's somewhat limited; Lazy<Dependency> works automatically but @Annotated Lazy<Dependency> requires you to explicitly add a binding. That's about as good as an extension can do. There are some alternatives:

1. Have Guice support its own Lazy<T> out of the box, in a similar way to how Provider<T> injection works now.
2. Have Guice expose some kind of support for "pluggable bindings." Then I could write something like bind(new LazyKeyMatcher()).to(new LazyGuicePlugin()) and the plugin would generate bindings on the fly.

Is there any interest in doing something like 2? If so I can code up a proof of concept.

[sameb]

Can you go into a bit more detail what you'd envision (2) being?

I'd also be willing to support something like (1), but wish we had a standard Lazy class so things could work for both dagger+Guice without needing to change user code. :-/

[tavianator]

Yeah if Lazy<T> made it's way into JSR 330 that'd be great. Is that feasible?

(2) would look something like this:

// Guice code
interface Binder {
    ...
    LinkedBindingPluginBuilder bind(Matcher<? super Key<?>>);
}

interface GuicePlugin {
    void createBinding(Key<?> key, Binder binder);
}

// Plugin code
class LazyKeyMatcher extends AbstractMatcher<Key<?>> {
    @Override
    public boolean matches(Key<?> key) {
        return key.getTypeLiteral().getRawType().equals(Lazy.class);
    }
}

class LazyGuicePlugin implements GuicePlugin {
    @Override
    public void createBinding(Key<?> key, Binder binder) {
        Type wrappedType = ((ParameterizedType) key.getTypeLiteral().getType()).getActualTypeArguments()[0];

        // Copy the binding annotation onto the wrapped type, if present
        PotentialAnnotation annotation = PotentialAnnotation.from(key);
        Key<?> wrappedKey = annotation.getKey(TypeLiteral.get(wrappedType));

        Provider<?> wrappedProvider = binder.getProvider(wrappedKey);
        binder.bind(key).toProvider(new LazyProvider(wrappedProvider));
    }
}

[mcculls]

2. sounds like the "autobinder" feature discussed in issue 49. I had a working patch which I used in the early version of a service-style extension, but the "autobinder" feature was considered too magical so instead I switched over to use the SPI to generate bindings ahead-of-time.

For 1) one approach is to use Scopes.SINGLETON to wrap the returned Provider<T> (you only need to do this if the underlying binding is not already scoped as a singleton) which will then give you the same instance for that returned provider instance. I use this technique here to return lazy entries.

[tavianator]

@mcculls Indeed, pretty much identical in fact. Actually I remember reading that bug report a while ago so it probably inspired this design. Should the WontFix be re-evaluated on that one? Admittedly I can't think of a motivating use-case besides Lazy<T>.

The Scopes.SINGLETON() trick is clever. I use it to implement my @LazySingleton scope, but didn't think of using it to implement/replace Lazy<T>.

[tavianator]

There's at least two cases in our internal codebase where this "plugin" thing would make sense. Actually everything boils down to the desire to bind Interface<T> to Implementation<T> for all T. So something less powerful than my initial suggestion could be used. How about the ability to do this:

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bindGeneric();
    }

    private <T> void bindGeneric() {
        bind(new TypeLiteral<Interface<T>>() { })
                .to(new TypeLiteral<Implementation<T>>() { });
    }
}

The generic method is just there to introduce a type variable. Guice would interpret bind(new TypeLiteral<Interface<T>>() { }) as applying for every possible T.

[sameb]

I think I could get behind something that supported Interface->Implementation, keeping the generics the same between the two. Edge cases we'd have to look out for:

• Interface<A, B> -> Implementation<A> -- dropping a generic type
• Interface<A> -> Implementation<A, ConcreteType> -- adding a concrete generic type
• Interface<A> -> Implementation<B> -- changing the generic types, IMO should fail
• Already bound Interface<Concrete> -> Implementation<Concrete> and attempting to do Interface<A> -> Implementation<B> -- should fail w/ a duplicate binding IMO

[gissuebot]

I'm up for a common Lazy. Mostly we need a place to put it. But if the
semantics are the same just roll a guice one that can inherit from the
common one and we can migrate them when we can release the common API
elements.

On Fri, Oct 17, 2014, 15:25 Sam Berlin notifications@github.com wrote:

I think I could get behind something that supported
Interface->Implementation, keeping the generics the same between the two.
Edge cases we'd have to look out for:

• Interface -> Implementation -- dropping a generic type
• Interface -> Implementation -- adding a concrete generic type
• Interface -> Implementation* -- changing the generic types, IMO
  should fail*
• Already bound Interface -> Implementation and attempting to do
  Interface -> Implementation* -- should fail w/ a duplicate binding IMO*

—

Reply to this email directly or view it on GitHub
#852 (comment).

--
You received this message because you are subscribed to the Google Groups
"github-migration" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to github-migration+unsubscribe@google.com.
To post to this group, send email to github-migration@google.com.
To view this discussion on the web visit
https://groups.google.com/a/google.com/d/msgid/github-migration/google/guice/issues/852/59584425%40github.com
https://groups.google.com/a/google.com/d/msgid/github-migration/google/guice/issues/852/59584425%40github.com?utm_medium=email&utm_source=footer
.

[stevenschlansker]

You could consider java.util.function.Supplier<T> instead of Lazy<T>. This would require JDK8, but maybe could be made to work with older JDKs too by protecting via reflection.

[sameb]

We're in talks about updating JSR330, so if Lazy goes in there we'd use that.

[cgruber]

The problem with Supplier for this (aside entirely from java8 questions)
is that it doesn't provide any semantic clarity over Lazy, since a
Supplier is free to create any number of instances, at the choice of the
implementer, whereas the Lazy interface is specified to provide one and
only one instance from get(), just it may defer initialization of that
instance. It implies memoization at the injection-site, rather than
memoization at the graph level, with deferred construction. Supplier
doesn't imply that contract at all, and if anything, is even more general
than Provider

On Wed Nov 19 2014 at 7:38:36 PM Sam Berlin notifications@github.com
wrote:

We're in talks about updating JSR330, so if Lazy goes in there we'd use
that.

—

Reply to this email directly or view it on GitHub
#852 (comment).

[tavianator]

I started looking into the generic binding thing, and I realised it's not quite powerful enough to implement Lazy<T> on top of, since it wouldn't work for @Named("foo") Lazy<Foo>. I can't think of a simple way to express such a "wildcard" binding either; maybe a special @Any annotation would work, but how would the implementation actually retrieve the real annotation?

So with that aside, would you guys accept a patch that added a guice-specific Lazy? Then if JSR 330 gets updated, it could be retrofitted on top just like Provider was.

[tavianator]

Ping? I'm happy to implement a Guice-specific version of Lazy as long as there's a chance it would get accepted.

[sameb]

We're cooking up something to make this work cross Dagger/Guice. I'll ping
here when it's ready.

On Wed, Dec 9, 2015 at 4:40 PM Tavian Barnes notifications@github.com
wrote:

Ping? I'm happy to implement a Guice-specific version of Lazy as long as
there's a chance it would get accepted.

—
Reply to this email directly or view it on GitHub
#852 (comment).