Sam Berlin wrote:
> I'm not sure I understand what you mean by, " I don't want to make it
> possible users of my library to directly inject ResourceConverter<T>
> into a class, but exclusively Provider<ResourceConverter<T>>".
>
> With Guice, if you say
>
> bind(Foo.class).toProvider(myFooProvider);
>
> and users can have both Foo & Provider<Foo> injected into their
> class. If the user opts to inject a Foo, it will be created by
> calling myFooProvider.get(). If a user opts to inject Provider<Foo>,
> then later get calls on that provider will call get on myFooProvider.
>
> Are you saying that you forcibly want to disallow users to inject
> Foo? If that's the case, your best bet is probably creating a
> separate custom interface called FooFactory and
> bind(FooFactory.class).toInstance(myFooFactory). (Still, I don't
> quite understand the rationale behind wanting to disallow direct
> injection of Foo.)
>
Thanks for your reply Sam. I won't go into the Factory direction because
it won't simplify the API.
The reason why I want to disallow direct injection is that, in my case,
it triggers recursive dependencies and ultimately fails (at runtime of
course).
The fact is that I have many ResourceConverter<T> implementations, I put
them all in a MultiMap<TypeLiteral<?>, ResourceConverter<?>>, and most
importantly, some special ResourceConverter<T1> depend on
ResourceConverter<T2>, and that's where my problems began!
My first solution to that problem was to create a Registry like that:
interface ConverterRegistry {
public <T> ResourceConverter<T> getConverter(TypeLiteral<T> type);
}
The idea was to avoid injection Map<TypeLiteral<?>,...> which is
cumbersome code.
This worked well, but it obliges end-users to:
1-get the registry
2- do a lookup (getConverter()) every time they need access to some
ResourceConverter<T>
Hence my idea of directly adding bindings (in addition to the MultiMap)
of ResourceConverter<T> to Providers that would do the lookup in the
Registry.
This worked fine as long as interested classes required the Provider
only (not the real object).
Since then, I wanted to find a way to force my users to inject the
Provider<T> to avoid runtime exceptions with recursive dependencies.
Is this clearer?
As I said, I can still deal with this problem by pure documentation, but
that would have been better to prevent it in the first place.
Cheers
Jean-Francois
> Sam
>
> On Mon, Nov 9, 2009 at 10:47 AM, Jean-Francois Poilpret
> <[email protected] <mailto:[email protected]>> wrote:
>
>
> Hi,
>
> I am currently trying to bind Provider<T> to some instance of
> CustomProvider<T> (where T is a more complex, generic type).
> But I get "Binding to Provider is not allowed" when I create the
> Injector.
>
> Although my code is much more complex (I have a generic helper method
> that can do the following for any T type, not just Icon as in the
> example below), I think it boils down to the following:
>
> binder().bind(new
> TypeLiteral<Provider<ResourceConverter<Icon>>>(){}).toInstance(new
> ConverterProvider<Icon>(Icon.class));
>
> where:
>
> class ConverterProvider<T> implements Provider<ResourceConverter<T>>
> {
> ConverterProvider(TypeLiteral<T> type) {...}
> public ResourceConverter<T> get() {...}
> }
>
> I don't really understand why Guice doesn't allow binding to a
> Provider?
> Actually I don't bind TO a provider, but I bind A provider TO an
> instance of that type (ie Provider...)! That's not exactly the same!
>
> Actually, the reason why I do that is that I don't want to make it
> possible users of my library to directly inject ResourceConverter<T>
> into a class, but exclusively Provider<ResourceConverter<T>>;
> isn't that
> possible with Guice?
>
> If not, that's not a real blocking problem, it would just make my
> API a
> bit weaker than it has to (aand then I'll have to put more emphasis on
> the javadoc;-))
>
> Thanks in advance for any feedback
>
> Jean-Francois
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
