Chris, We have a number of use cases in our system. Let me describe two below.
1. We use the JsonMarshaller (http://code.google.com/p/ jsonmarshaller/) for convert POJOs to and from JSON. This library provides you with marshallers. EntityMarshaller<T> which lets you marshall instances of T. You create such marshaller using TwoLattes.createEntityMarshaller(T.class); We want to be able to tell to Guice "for literals matching Marshaller<X> provide an instance using createEntityMarshaller(X)". 2. Proxy objects. We have objects such as Proxy<T extends InterfaceFooBar> which provide memoizing capabilities to cache expensive operations. We need to get these proxies whenever we want to do meta-level operations on T. Having jit providers makes it trivial. To your point about jit providers producing more run-time errors, I beg to differ. In our system, we've had a number of cases where we forgot to list a specific type for which wanted a marshaller... using jit providers ensures we have implementations for all types. In this sense, it provides additional safety and makes Guice even more friendly. In general, jit providers simply fill the void for user defined jit capabilities. Guice has a number of those already @ProvidedBy, @ImplementedBy, no arg constructor, etc. Also, I do not see how lifecycle has anything to do with jit providers. These two concerns seem orthogonal to me. PL On Jun 1, 4:49 am, Christian Edward Gruber <[email protected]> wrote: > Can you talk through the use-cases for user-defined just-in-time > bindings? As far as I can see, using providers to obtain just-in-time > binding behaviour is highly dangerous. i can imagine some leegitimate > use-cases for it, but most of the time when people talk about such > things (often injecting a Provider as a workaround) they really are > trying to workaround Guice's lack of lifecycle support. > > One of my deepest concerns with JIT bindings is the wonderful way in > which it moves your wiring errors JIT as well, which makes debugging > more difficult, and can result in learning about such errors in > production AFTER deployment, depending on the particular layout and > timings of your injections. So, powerful, but dangerous and there > might be more suitable ways to accomplish what you want. > > What would you need just-in-time bindings for? > > Christian. > > On May 31, 2010, at 11:12 PM, Pascal-Louis wrote: > > > Hi all, > > > We've had a long standing grudge against Guice (which we love in all > > other respects!): the inability to have user-defined just-in-time > > bindings. > > > Over the course of the long weekend, I've implemented this feature and > > would love some feedback. Check it out on > >http://eng.kaching.com/2010/05/just-in-time-providers-for-guice.html. > > > I would specifically appreciate feedback from the Guice team on the > > process to integrate this patch into trunk. On a more tactical note, I > > was unsure about which injection points to use, see the ??? comment in > > the method > >http://github.com/pascallouisperez/guice-jit-providers/blob/master/sr... > > . > > > Best, > > PL > > > -- > > You received this message because you are subscribed to the Google > > Groups "google-guice-dev" group. > > To post to this group, send email to google-guice- > > [email protected]. > > To unsubscribe from this group, send email to > > [email protected] > > . > > For more options, visit this group > > athttp://groups.google.com/group/google-guice-dev?hl=en > > . -- You received this message because you are subscribed to the Google Groups "google-guice-dev" 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-dev?hl=en.
