FYI, I submitted an improvement
https://github.com/google/guice/commit/842f351c4b2b3b0a90d9f3bcf164d8fd19aede6c
to this the other day so that when frameworks call
*OptionalBinder.newOptionalBinder(binder(),
Foo.class)*, then users can supply the binding by just calling
I like it, similar to what Dagger has for @Provides(SET).
I also really like OptionalBinder. Previously I used Modules.override(new
OverridableBindingsModule(), ...) to provide default implementations.
On Wednesday, 2 April 2014 09:41:45 UTC-4, Sam Berlin wrote:
I've been thinking also about
I'm very excited about this; are you going to cut another beta release
anytime soon?
Is it possible to extend this to use other wrapper classes? I'd like to add
this to the Scala-Guice project for Scala's option class if possible.
On Apr 1, 2014 7:33 PM, Sam Berlin sber...@gmail.com wrote:
Ever
No way to extend it to provide other wrapper classes, no. Although you
could pretty easily write a wrapper around it (e.g, ScalaOptionBinder) that
binds your custom wrapper to something that delegates to OptionalT (and
OptionalProviderT, etc.). That'd require users to use your wrapping
binder,
Yeah - I can see Dagger borrowing back the approach for Optional
provides, though having no access to an Optional in dagger is tricky
(targeting Java6 without non-JSR dependencies, like Guava). We'll have
to figure it out. At least we might be able to do the default approach
though.
c.
On
Let's get the OSGI fix in, and THEN cut beta5.
c.
On 2 Apr 2014, at 10:57, Sam Berlin wrote:
No way to extend it to provide other wrapper classes, no. Although
you
could pretty easily write a wrapper around it (e.g, ScalaOptionBinder)
that
binds your custom wrapper to something that
We can likely make this work for scala-guice in a similar manner to the
Multibinder wrapper.
Thomas Suckow
On Wed, Apr 2, 2014 at 11:09 AM, Christian Gruber cgru...@google.comwrote:
Let's get the OSGI fix in, and THEN cut beta5.
c.
On 2 Apr 2014, at 10:57, Sam Berlin wrote:
No way to
