As I (firmly :) insisted in the discussion we had at eclipsecon I think the place to do this is in the ContextObjectSupplier (where the lookup rule is), the extender of the primary OS or somewhere in the InjectorImpl. The extended OS is meant to give the power to extend the DI engine in terms completely unrelated to contexts. If you decide to use Extended OS you are agreeing that you don't want to know about contexts and want to implement the mechanism of supplying objects yourself, much like the Event and Preference OS.
Even though it sounds useful I don't think we should hardcode this into the ContextOS (if I'm right and it's the right place to put it) or InjectorImpl, much like @Optional and friends is. Sopot On Tue, Apr 2, 2013 at 1:09 PM, Lars Vogel <[email protected]> wrote: > Hi, > > on EclipseCon Wim, Sopot and I discussed how we could implement @Adapt as > discussed earlier in this group. As a reminder we were discussion to create > a new annotations to do the adaption automatically like in the following > example: > > ----------- > @Inject > public void someMethod(@Optional @Adapt > @Named(IServiceConstants.Active_Selection) > Person person) > ---------- > > I think it would be useful if we could use an ExtendedObjectSupplier for > this, so that the core of the DI framework stays simple and lean. > Unfortunately AFAIK ExtendedObjectSupplier does not provide access to the > current context. > > Is this by design or would it be possible to pass the current context to > the ExtendedObjectSupplier? > > Best regards, Lars > > _______________________________________________ > 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
