It is necessary to maintain support for the current state, where two
different implementations can co-exist as a singleton. Consider:
bind(Server.class).annotatedWith(named("public")).to(ServerImpl.class).in(Scopes.SINGLETON);
bind(Server.class).annotatedWith(named("private")).to(ServerImpl.class).in(Scopes.SINGLETON);
If places inject the named Servers and can add handlers to server pages, it
would be important to separate the instances of the public & private server,
so things don't intermix.
I agree that at first it can be a little confusing when the result isn't
what you expect, but I'm not certain there's any way to make it clearer. If
the result *is* what you expect, it's very clear. The above bindings, for
example, do seem to imply -- without prior knowledge -- that two different
instaces of ServerImpl will exist. Where it isn't clear is perhaps when
annotations aren't involved, and you're just trying to bind different
superclasses/interfaces to a single result type. Unfortunately, I don't
think it would make sense to muddy the API and make it so the resolution of
the scope is dependent on if an annotation was used. That seems even more
complicated.
sam
On Mon, Jun 7, 2010 at 7:40 PM, Tim Boudreau <[email protected]> wrote:
> On Jun 7, 4:30 am, "Dhanji R. Prasanna" <[email protected]> wrote:
> > Actually once you grok that everything in Guice is key-based and not
> class
> > based, a world of clarity opens up =)
>
> Given that Key is based on TypeLiteral (emphasis on "literal"), I
> believe what you are saying is that there is no way to do what what we
> are talking about other than:
>
> bind(B.class).in(Scopes.SINGLETON);
> bind(A.class).to(B.class).in(Scopes.SINGLETON);
>
> bind(Singleton.class).to(B.class).in(Scopes.SINGLETON);
>
> This seems painfully verbose, with or without a world of clarity.
>
> > In that regard I believe we have one of the best balanced APIs between
> > flexibility and correctness.
>
> I am definitely in favor of correctness, and keeping Guice tied to
> literal types is certainly a good decision. Nonetheless, I believe
> the ability to bind a specific range of types without explicit bind()
> calls for each direct supertype would not in the least sacrifice
> correctness. More importantly, without support from Guice itself it
> is, as far as I can tell, to implement such a feature in a client
> Module without the counter-intuitive side effect that the one type
> which *cannot* be injected is the actual implementation class.
>
> > I certainly understand, however that this may
> > not be your first reaction upon uncovering this Guice property.
>
> Would you not agree this could be solved more elegantly, without
> sacrificing anything?
>
> -Tim
>
> --
> 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]<google-guice%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
>
--
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.
