No need for iterating over the handler map, right?

$commandClass ===get_class($command);if (isset($handlerMap[$commandClass])) {$handler =$handlerMap[$commandClass];return$handler->handle($command);}

(or even using null coalesce operator) ? 😄

We should avoid typehinting on ServiceLocator (should be internal anyway, right??) but rather use the PSR-11ContainerInterface instead, right?

[...], but still are instantiated uselessly. (might not be the best phrasing)

done, also moved the "Service locators are intended to solve this problem" just after this "wrong" example in order to know what it solves before reading it

Why do you type hint against this interface? Simple closure is enough, isn't it?

$this->psr11->get(get_class($command)) makes me think thatFoo\RegisterUser is a service name, but semantically it isn't.

Goal is to show the provided PSR-11 implem first, so it's clear what you can do when receiving such argument, including throwable exceptions. Just below there's an example showing that it can be used as a callable and how it can be used

I'm not even sure that PSR-11 makes sense for this feature at all. In this context PSR-11 looks like a replacement for the Java'sMap: you need some generic explicit interface, withNotFound* exception andget/has methods, but PHP doesn't have it (ArrayAccess is kinda similar, though), so here we go.

Yes, PSR-11 mapsstring onobject, but semanticallystring here is notserviceId, but something more generic. It looks like far-fetched concept here.

I can't imagine case when I need to type hint against the PSR-11 interface unless I really do something highly cohesive with DI-containers, where I want to say explicitly: "yes, this is about DI-containers", e.g. decorator for DI-containers which logs service ids.

Second example with callable looks for me better even if it has implicit interface. At least, it has nothing to do with DI-containers.

So the example with PSR-11 interface looks a bit unnatural for me. Probably, it's just me. Just my 5 cents.

Yet I understand your concerns, I think PSR-11 is legit in this context since the primary goal of the locator is to fetch services from the DIC (keeping in mind that this doc is about symfony/DI).
I find the callable typehint useful for cases where there's no DIC behind the locator, which should not be the main usage of this feature to me since it is first built to avoid container-aware stuff inside the symfony full stack.

semantically string here is not serviceId, but something more generic. It looks like far-fetched concept here.

In my opinion, services identifiers should remain the same in the locator than in the container from which they come from, so they're safely accessible no matter which container/registry/locator/provider is given to you, that is primordial to me.
Redefining identifiers might just be useful in some cases that I'm still not sure to get, but it seemed logic for others so here we are.

Second example with callable looks for me better even if it has implicit interface. At least, it has nothing to do with DI-containers.

As you pointed out in the code PR, container is just a kind of map after all and if you ask me, PSR-11 could be calledObject[Store|Provider|Locator|Registry] instead ofContainer.

Should not forget to remove this, asServiceLocator doesn't implementIteratorAggregate anymore. :)

return call_user_func($this->handlerMap, $handlerId)->handle($command);?

You may write the constructor here to understand the correlation between the service declaration and the class instanciation

You're right, definitely needed for a good understanding.

It's confusing that the service ID of the handler is the fqdn class name of another class
At first I thought it was the same class and I wonder why you ask to the services locator something you already have.. :/

The command bus I use just works like that :) Handler services take a tag including the command class and are resolved exactly like this when callingCommandBus::handle(), it's the better example I found

Sometimes it happens that we inject '@doctrine' in some manager to use it as a locator and lazy load repositories, because its methods may require one or more of them, but some would argue that you should explicit your dependencies in the constructor no matter what. I think that in such case in the future I would opt for this new feature instead, hoping that a plugin will handle the autocompletion before then :).

Maybe a dot would fit after "used" as well? What about an example?

Sometimes it happens that we inject '@doctrine' in some manager to use it as a locator and lazy load repositories, because its methods may require one or more of them, but some would argue that you should explicit your dependencies in the constructor no matter what. I think that in such case in the future I would opt for this new feature instead, hoping that a plugin will handle the autocompletion before then :).

$this->handlerMap ?
(same below)

Why not only$handler = $this->locateHandler($commandClass);?

I guess you mean$this->handlerLocator($commandClass) :).
Anyway, the intermediate variable is mandatory, calling$this->handlerLocator() would make the engine look for ahandlerLocator() method instead of executing the property as a callable.

The intermediate variable assignment is necessary for php to understand it's a callable property, and not a method.
But as of PHP7, it could be$handler = ($this->handlerLocator)($commandClass)

Indeed, good to know. Let's stay simple there though

(But this is documentation. I think the current code sample is great for this purpose 😄 )

Ok guys, thanks!

I recently implemented a service locatorfor API Platform and the syntax described here is currently not the correct one.

According tosrc/Symfony/Component/DependencyInjection/Compiler/ServiceLocatorTagPass.php#L40-L42, this should be:

->setArguments([    ['AppBundle\FooCommand' =>newReference('app.command_handler.foo'),'AppBundle\BarCommand' =>newReference('app.command_handler.bar'),    ],])

Same for the YAML/XML config.

Indeed, fixed. Thanks!