The named singleton was one of my motivating factors, where the instance you received could be scoped based on annotations / qualified name. However, because the instance must exist when the binding is created, the injected instance is not further injected (nor do I feel it should be).
This approach does not change the existing injection hierarchy: - providers - local supplier (local contexts) - primary supplier (primary context) - extended supplier - bindings - creatable's Even though it is counter to their purpose, you are able to inject providers with a specific instance. (My thought was I cannot save you from yourself every time.) When invoking get() from a provider, it will first search for any bindings. Instead of assuming there is an implementation class, it will check for an instance and return that, if it exists. The only alternative would be throwing an exception, which I would be open to. (This is the only alternative because a TypedBinding can only be associated with an instance or implementation, not both.) The next step will be creating an injector hierarchy similar to contexts, where the injector can be more closely associated with groups of suppliers. Then in the case of RAP, your parent injector could be associated with "global" bindings/suppliers and each workspace could have its own injector. The intention being to reduce the amount of time spent resolving arguments, it's at least something to think about. JD On Fri, Sep 14, 2012 at 5:27 PM, Brian de Alwis <[email protected]>wrote: > That sounds like it could be nifty. It's a bit like the class-based > @Singleton, but named. Do you further inject the provided instance? > > I assume it overrides any values provided from a supplier (e.g., context)? > > Brian. > > On 14-Sep-2012, at 3:39 PM, Joseph D Carroll Jr wrote: > > I just released an enhancement for the DI engine that allows for the > creation of (what I am calling) typed bindings: > http://bugs.eclipse.org/bugs/show_bug.cgi?id=389634 > > Here is an example of what you are able to do with typed bindings: > injector.addTypedBinding(String.class).toInstance("My string"); > injector.addTypedBinding(String.class).named("NAMED").toInstance("Some > other string"); > > injector.addTypedBinding(FooBar.class).annotatedWith(MyAnnotation.class).toInstance(myFooBarImpl); > > injector.addTypedBinding(FooBar.class).named("NAMED").annotatedWith(ExecuteMe.class).toInstance(someOtherFooBarImpl); > > injector.addTypedBinding(FooBar.class).annotatedWith(MyOtherAnnotation.class).named("NAMED").toImplementation(FooBar.class); > injector.addTypedBinding(TestSingleton.class); > > I am certainly open to, and looking for, comments and will continue to > make enhancements and any fixes. In the next few days I will put together > a little better documentation. > This implementation is also 100% backwards compatible with the current > bindings. > > The code is hosted here: > > http://github.com/jd-carroll/eclipse.platform.runtime/tree/TypedBindings/bundles/org.eclipse.e4.core.di > > > JD > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
