Add type mapping support for container ID override

[henriquemoody]

The Resolver resolves parameters by looking up types directly in the container using ->get(). This doesn't work when:

1. Multiple implementations of an interface exist in the container, and you need to specify which one
2. Services are registered with string aliases (e.g., 'my.favorite.animal') instead of class names

Currently there's no way to tell the Resolver "when this callable needs an Animal, look up 'my.favorite.goat' from the container."

Introduce a new interface ParameterResolverWithTypeMap extending ParameterResolver with an additional method:

interface ParameterResolverWithTypeMap extends ParameterResolver
{
    public function resolveWithTypeMap(
        ReflectionFunctionAbstract ,
        array ,
        array<string, string> 
    ): array;
}

Usage:

$args = $resolver->resolveWithTypeMap(
    $reflection,
    $arguments,
    [Animal::class => 'my.favorite.goat']
);

The Resolver class would implement both interfaces, maintaining backward compatibility.

Additional context

This approach preserves backward compatibility - existing code using ParameterResolver continues to work unchanged. Clients can build the type map externally based on their needs and pass it at call time.

[henriquemoody]

Alternatively, we could just add another argument to resolve(), something to consider

[alganet]

I understand the appeal of having this. I would go for another direction though, keeping the resolve interface pristine and using the type map in the constructor, maybe adding another resolver:

$r = new NewMysteriousResolverName($container, [
    Animal::class => 'my.goat'
]);
$r->resolve(...);

That solves the "when this callable needs an Animal, look up 'my.favorite.goat' from the container." problem.

If you need granular, per-call, you can just look up the container first:

$r = new ContainerResolver($container);
$r->resolve(..., ['animalParam' => $container->get('my.goat')); //actually reads simpler than the map for this case

When we collapsed resolve and resolveNamed, we lost free-form type resolving (before: any type would match; now: type and position should match). We could also try to recover that to make it easier for granular calls.

---

Most importantly, is there a specific use case you envision using this for? Having a concrete scenario might help shaping up the design.

[henriquemoody]

I'm thinking about the Validation use case, but it's a generic issue.

Passing those on the constructor was my first instinct, but there are some problems with that. It could be that the constructor of both ClassA and ClassB have both Animal as dependency, but each one want a specific type of animal to be passed to it.

My second instinct was to pass a map to the constructor of the ContainerResolver that would say something like ClassA::__construct => Goat, ClassA::__construct => Sheep but that would then mean that the ContainerResolver would need to establish a vocabulary to declare those (for ANY callable), which I think becomes a bit too complicated to my taste, apart from the fact that we would then need to also use the getDeclaredClass(), which would give us some headache in terms of performance.

At last, I thought that passing a map on runtime would be better, since we want to use the same ContainerResolver multiple times instead of always creating a new instance (otherwise the user cannot customize their resolver).

For the Validation use case, in which we want to create validators reusing dependencies that are already present in the container, we would have to let the Fluent be informed of the mapping (via Validation/FluentFactory). Then we could allow users to inform (thought the DIC) how the mapping looks like ([CountryCode => [Countries::class => 'my.countries'])). Of course, we could also just have the mapping in the container directly, and just forget about the new argument, I'm just not sure we want this to be so implicit, it seems like something that belongs to the Resolver.