Lacking injection point information when using the deprecated DependenyChain replacement.

[Cybermaxke]

The provided example to replace the deprecated dependency chain method doesn't provide enough context about which field or parameter is being injected. I tried to replace dependency chain method, but the most accurate I got was knowing which method/constructor/class is being injected.

Knowing which field/parameter is being injected allowed Providers to return values based on the annotated elements, without having to bind each possible combination.

The dependency chain solution can be found in the following PR changes: https://github.com/SpongePowered/SpongeCommon/pull/1435/files/1bd19db6f0b2363b8bc72960df0b0947e04cc1e0
A custom InjectionPoint is constructed from the information in the dependency chain, this object only exposes the annotations/type/target type of the field/parameter. There is also a small example available in the PR.

Then I was looking for a different solution for the dependency chain and ended up stuck in the following changes:
LanternPowered/Lantern@f67d3e8

Not sure what the best solution could be to resolve the issue, undeprecating the getDependencyChain method is an option. Or similar to the InjectionPoint injection, could it also be done for the Dependency by guice itself, making it unnecessary to scan the chain. Maybe you guys can find a better solution for this issue. Maybe there is even a different solution that I haven't been able to find.

[kashike]

I'm going to give this a bump - any solution known? If not, is it possible to have this reverted?

[kashike]

I hate to be one of those people who bumps so often, but it'd be great to get a response on this - @dimo414?

[dimo414]

@kashike sorry, I'm afraid I don't have any insights here.

[Cybermaxke]

The DependencyChain got deprecated in the following commit: 99c1047
And one of the reasons it being depecrated was not being "popular" enough and guice being more performant when removing it (A benchmarking experiment* shows that maintaining the dependency stack costs about 10% of guice performance. Anecdotally this feature also isn't very popular, so eliminating it seems reasonable.). Maybe a opt-in solution would be better instead of removing it?

Or maybe a method to retrieve the dependency chain without the source (would reduce the internal dependency stack size by half: https://github.com/google/guice/blob/master/core/src/com/google/inject/internal/InternalContext.java#L46).

[kashike]

@lukesandberg - input?

[kashike]

another poke, @lukesandberg - input?

[kashike]

I'm going to give this yet another poke - @lukesandberg?

[kashike]

I'm going to give this yet another poke to try to get some kind of answer from the Guice team, please.

[sameb]

Hi Folks -- Apologies for the lengthy delay in replying here. As commented on #1721, where @kashike proposed a relatively clean API for doing this... this is not something we're likely to incorporate into Guice.

Changing what a Provider creates based on arbitrary data associated with the injection point that's being injected has thus far been an explicit anti-goal of Guice. If the returned type can change based on who's requesting it, that makes reasoning about the object graph much harder.

Additionally, as far as quirks of the API go, I can't imagine how this would work with scopes. A straightforward implementation would capture whatever the first return value is & replay it to other injection points. That would be wrong, though I don't know what "right" should even be.