[DI] Replace container injection by explicit service locators #21553

chalasr · 2017-02-07T08:45:16Z

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#20658
License	MIT
Doc PR	symfony/symfony-docs#7458

This adds a new ServiceLocatorArgument (!service_locator) argument type which takes a list of services, meant to be used as a concrete service locator in order to avoid the remaining needs for injecting the container when it's only a matter of dependency lazy-loading.

Config:

App\FooBar: [!service_locator { key1: '@service1', key2: '@service2' }]

<service class="App\FooBar" public="false">
    <argument type="service-locator">
        <argument type="service" key="key1" id="service1"/>
        <argument type="service" key="key2" id="service2"/>
     </argument>
</service>

new ServiceLocatorArgument(array('key1' => new Reference('service1'), 'key2' => new Reference('service2'));

Usage:

$locator->has('key1') // true
$locator->has('service1') // false, the defined key must be used
$locator->get('key1'); // service1 instance
$locator->get('service1'); // exception
$locator->has('not-specified') // false
$locator->get('not-specified'); // exception

We have some concrete use cases in the core where this would be useful (see e.g. SecurityBundle's FirewallMap), same in userland/3rd party code (see related RFC).

ogizanagi · 2017-02-07T09:11:39Z

WDYT about using tags on each service available through a locator instead of listing the services as the locator arguments?

Something like:

<service id="MyServiceAvailableThroughALocator" class="...">
    <!-- ... -->
    <tag name="service.locator" locator="locator_name" alias="service_alias_within_the_locator" />
</service>

Then any service can declare it is available through a named locator, and can provide an alias used to identify it within the locator itself.

jvasseur · 2017-02-07T09:30:30Z

Does it allow mapping keys to services like this ?

App\FooBar:
    arguments:
        - =locator:
            foo: '@service1'
            bar: '@service2'

I think most of the time it's what is needed since you need to map the service id to some kind of alias used by the component receiving the locator.

chalasr · 2017-02-07T09:35:02Z

@ogizanagi As discussed, I find more adapted to let the locator consumers defining explicitly which services they need rather than asking each service to define from which service locator(s) they can be accessed. The service being already in the container, to me it's fine to request it, as when using other lazy arguments. I don't see the need for extending the ServiceLocator itself in userland, nor restricting which services should be accessed by a locator elsewhere than the service using the locator itself, even if the idea is interesting.
Discussion stays open if others think it's a good idea.

@jvasseur Right now it doesn't, but it makes sense to me and adding it should not be hard.

stof · 2017-02-07T09:35:15Z

@ogizanagi when a service needs a service locator, it has a single service locator, not multiple ones.
Services needing a service locator will often fill it using a tag. But it is better to keep using separate tags for each use case instead of transforming them all into <tag name="service.locator" locator="..." />

ogizanagi · 2017-02-07T09:38:43Z

@stof

when a service needs a service locator, it has a single service locator, not multiple ones.
Services needing a service locator will often fill it using a tag. But it is better to keep using separate tags for each use case instead of transforming them all into

I think you misunderstood me (or am I misunderstanding you?). I updated my comment since, though, in order to show a more complete sample.
I don't want to tag a service needing a locator instance, but instead tag each service being available through a locator (maybe the service.locator tag name isn't right).
This means being able to extend the list of available services of a well identified locator on userland or from third-party bundles.

stof · 2017-02-07T09:57:08Z

@ogizanagi bundles wanting to make the list extendable should use their own tags, allowing to keep things more understandable, and more flexible (the bundle can do extra processing of the tagged services in the compiler pass, or expect additional attributes).
Forcing to handle all collecting in a single compiler pass defined in Symfony itself is less powerful for bundles, and has a worse DX (and it leaks implementation details about the usage of the ServiceLocator feature in the bundle, while the bundle should be free to refactor the way it actually injects the services).

stof · 2017-02-07T09:57:52Z

thus, it would also force to add an identifier on locators (to reference them in your proposed tag), which goes against the architecture of arguments

chalasr · 2017-02-07T09:58:01Z

This means being able to add services to a well identified locator on userland or from third-party bundles.

I'm not sure about the usefulness of defining service locators as services, as use cases are quite specific (most of the times only one service needs a given range to be accessible f.i. CommandBus, FirewallMap).

If one needs two services with the same locator, then the services should be quite related IMO, so it can be solved by defining a parent service defining the locator argument and children would inherit this argument (e.g. Console command needing access to console helpers).
Right now I don't see a concrete need for having well identified locators nor creating custom ServiceLocator implementations in userland.

ogizanagi · 2017-02-07T10:11:45Z

@stof : Understood. Finally, I agree. Thanks.

chalasr · 2017-02-07T10:54:19Z

@jvasseur Updated to support mapping keys to services

Taluu · 2017-02-07T10:57:34Z

src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php

+            $getterCode .= '        }';
+
+            $hasserCode = 'function ($id) {'."\n";
+            $hasserCode .= sprintf('            $references = array(%s);', implode(', ', $servicesMap));


sprintf('$references = %s;', var_export($services, true)); ?

(Sorry, moved my comment here, as it seemed more appropriate)

@Taluu I tried it and in fact we only need a string map here, while var_export dumps Reference objects. Also looping over references is actually needed for generating the getter code so I think it can be kept as is, unless another existing helper exists for such

Taluu · 2017-02-07T11:04:24Z

src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php

+            $hasserCode = 'function ($id) {'."\n";
+            $hasserCode .= sprintf('            $references = array(%s);', implode(', ', $servicesMap));
+            $hasserCode .= "\n\n".'            return isset($references[$id]) || in_array($id, $references, true);';
+            $hasserCode .= "\n        }";


More a question of tastes and all, but instead of several concatenations, I would have used a nowdoc instead :

<?php // ... $hasserCode = <<<'EOD' $references = ... EOD;

Not excluding a call to sprintf afterwards, of course

stof · 2017-02-07T08:49:50Z

src/Symfony/Component/DependencyInjection/Argument/LocatorArgument.php

+ *
+ * @author Robin Chalas <[email protected]>
+ */
+class LocatorArgument extends IteratorArgument


it should not extend IteratorArgument. A LocatorArgument is not an IteratorArgument (something checking for iterator arguments should probably not be triggered for locator arguments)

It was a mistake, fixed.

nicolas-grekas

the map must be explicitly keyed

nicolas-grekas · 2017-02-07T20:52:25Z

src/Symfony/Component/DependencyInjection/Argument/LocatorArgument.php

+    private $values;
+
+    /**
+     * @param Reference[] $values


doesn't have to be only references - the yaml loader currently supports any kind, which is nice I think - same for the xml loader

Does that mean $v = $v instanceof Reference ? $v : new Reference($v); should be used, or do you have something else in mind (keep scalars, parameters)?

Nope, the values can really be anything, references or arrays or scalars

Given ContainerInterface::get() must return an object, scalars should be returned by getParameter(), right?

nicolas-grekas · 2017-02-07T20:54:08Z

src/Symfony/Component/DependencyInjection/Argument/ServiceLocator.php

+/**
+ * @author Robin Chalas <[email protected]>
+ */
+final class ServiceLocator


should implement ContainerInterface to me

Should we mark it as internal also so that we discourage it from being used in type hints?

should implement ContainerInterface to me

I hesitated to, sounds good to me. However, since yaml/xml file loaders can return references, should we just ignore their invalid behavior and use the one passed to ServiceLocator::get()?
Also, should it make some noop for e.g. get/setParameter(), or should it truly implement that?

Maybe we could make it implement the ArrayAccess interface. It would allow consumer interfaces to use array|ArrayAccess as a type hint and use it like an array.

@nicolas-grekas : Just to be sure: You're talking about PSR-11's ContainerInterface, right?

Yes psr-11 will solve part of the problem (it solves the coupling with the symfony framework).

But let's say we use this feature for some symfony component (Form Types could be an example), if i want to use this component outside the symfony framework I would need to : require an psr-11 container, instantiate it with the services I want and then pass it to the component when I could just use a PHP array.

You're just looking for psr-11

PSR-11 is still about DI containers. It semantically couples the code with dependency injection container concept. This is odd: I don't want to know whether it is container or simple array-like map of "command handlers". DI container is just specific type of a map.

@jvasseur @unkind you're missing eg exceptions - the wording about them in PSR-11 is a requirement here also. ArrayAccess is not an interface - it's just an magical incantation for the engine.

to use this component outside the symfony framework I would need to : require an psr-11 container

???: this would be an implementation of PSR-11, so you'd need nothing else really.

I'm talking about using a component outside of a DI container so yes you would need to require one.

you're missing eg exceptions - the wording about them in PSR-11 is a requirement here also

What exactly do we miss? You shouldn't access array field without checking whether it exists. So you won't face the NotFoundException (the only checked exception in PSR-11, btw) or your code is just broken.

nicolas-grekas · 2017-02-07T21:01:12Z

src/Symfony/Component/DependencyInjection/ContainerBuilder.php

+        } elseif ($value instanceof LocatorArgument) {
+            $references = $value->getValues();
+            $value = new ServiceLocator(function ($id) use ($references) {
+                return isset($references[$id]) || in_array($id, array_map(function ($ref) { return (string) $ref; }, $references), true);


the in_array part looks wrong to me - keys must be the ony way to reference values

nicolas-grekas · 2017-02-07T21:01:46Z

src/Symfony/Component/DependencyInjection/ContainerBuilder.php

+                    return $this->get($references[$id], $references[$id]->getInvalidBehavior());
+                }
+
+                return $this->get($id, $references[array_search($id, $references)]->getInvalidBehavior());


keys must be the only way to reference values

nicolas-grekas · 2017-02-07T21:03:11Z

src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php

+                $getterCode .= $singleGetter;
+            }
+            $getterCode .= '        }';
+            $hasserCode = 'function ($id) {'."\n";


given that keys should be the only way to reference values, instead of hasser+getter, I'd suggest generating a single Closure[], keyed by "public" service name

nicolas-grekas · 2017-02-07T21:15:37Z

This should be marked as experimental also.
And thanks for working on it :)

chalasr · 2017-02-07T22:30:45Z

Status: needs work

😅

fabpot · 2017-02-13T09:19:53Z

src/Symfony/Component/DependencyInjection/Argument/ServiceLocatorArgument.php

+    private $values;
+
+    /**
+     * @param array $values An array of mixed entries indexed by identifier


That does not help that much. But now I realize that I've missed something in this PR. This allows to inject both services and parameters, right? But a service locator is really about giving access to services only, not parameters. Any use case for having parameters as well?

That's PSR-11 - return type of "get" is mixed for this reason - same as eg Pimple ;)
I see no reason to forbid non-objects - that won't provide any technical benefit (even if I won't use that much myself).

Please see #21553 (comment). There's no explicit notion of parameters here, only services to get() but services can be any value. I have no strong opinion about, but that's PSR-11 compliant and I don't see any reason to forbid it in fact.

Let me be very clear: I don't care about PSR-11. Let's go back to the basics instead. A service locator must return services. So, let's do that.

And as far as Pimple is concerned, please keep in mind that this is a toy, a joke, not the holy grail of dependency injection, so mentioning it here is pointless :)

Docblock and tests updated to expect only references.

It now throws on non-reference values

nicolas-grekas · 2017-02-13T09:50:01Z

src/Symfony/Component/DependencyInjection/Argument/ServiceLocatorArgument.php

+    private $values;
+
+    /**
+     * @param array $values An array of references entries indexed by identifier


Reference[] + validity check in the constructor? maybe also in loaders if that can provide more useful error messages?

[SecurityBundle] Avoid container injection in FirewallMap

fabpot · 2017-02-13T14:17:39Z

Thank you @chalasr.

@service2

…ocators (chalasr) This PR was merged into the 3.3-dev branch. Discussion ---------- [DI] Replace container injection by explicit service locators | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #20658 | License | MIT | Doc PR | symfony/symfony-docs#7458 This adds a new `ServiceLocatorArgument` (`!service_locator`) argument type which takes a list of services, meant to be used as a concrete service locator in order to avoid the remaining needs for injecting the container when it's only a matter of dependency lazy-loading. Config: ```yaml App\FooBar: [!service_locator { key1: '@Service1', key2: '@service2' }] ``` ```xml <service class="App\FooBar" public="false"> <argument type="service-locator"> <argument type="service" key="key1" id="service1"/> <argument type="service" key="key2" id="service2"/> </argument> </service> ``` ```php new ServiceLocatorArgument(array('key1' => new Reference('service1'), 'key2' => new Reference('service2')); ``` Usage: ```php $locator->has('key1') // true $locator->has('service1') // false, the defined key must be used $locator->get('key1'); // service1 instance $locator->get('service1'); // exception $locator->has('not-specified') // false $locator->get('not-specified'); // exception ``` We have some concrete use cases in the core where this would be useful (see e.g. SecurityBundle's FirewallMap), same in userland/3rd party code (see related RFC). Commits ------- e7935c0 [DI] Replace container injection by explicit service locators

lsmith77 · 2017-02-14T20:26:09Z

https://github.com/liip/LiipContainerWrapperBundle :)

chalasr · 2017-02-14T20:30:34Z

@lsmith77 A great precursor :)

…ocators (nicolas-grekas, chalasr) This PR was merged into the 3.3-dev branch. Discussion ---------- Remove some container injections in favor of service locators | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #21553 (comment) | License | MIT | Doc PR | n/a Commits ------- 8293b75 Replace some container injections by service locators 0be9ea8 [EventDispatcher] Fix abstract event subscribers registration

…ocators (nicolas-grekas, chalasr) This PR was merged into the 3.3-dev branch. Discussion ---------- Remove some container injections in favor of service locators | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#21553 (comment) | License | MIT | Doc PR | n/a Commits ------- 8293b753cf Replace some container injections by service locators 0be9ea8ba1 [EventDispatcher] Fix abstract event subscribers registration

…ocators (nicolas-grekas, chalasr) This PR was merged into the 3.3-dev branch. Discussion ---------- Remove some container injections in favor of service locators | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#21553 (comment) | License | MIT | Doc PR | n/a Commits ------- 8293b75 Replace some container injections by service locators 0be9ea8 [EventDispatcher] Fix abstract event subscribers registration

…ocators (nicolas-grekas, chalasr) This PR was merged into the 3.3-dev branch. Discussion ---------- Remove some container injections in favor of service locators | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#21553 (comment) | License | MIT | Doc PR | n/a Commits ------- 8293b753cf Replace some container injections by service locators 0be9ea8ba1 [EventDispatcher] Fix abstract event subscribers registration

…guiluz) This PR was merged into the master branch. Discussion ---------- [DI] Add section about service locators Adds documentation for symfony/symfony#21553 and symfony/symfony#22024. Any suggestion will be much appreciated, as usual. Commits ------- fa19770 Fix service locator declaration f5e4942 Rewords 5efacd0 [DI] Add section about Service Locators

carsonbot added Status: Needs Review DependencyInjection Feature labels Feb 7, 2017

chalasr mentioned this pull request Feb 7, 2017

[DI] Replace container injection by explicit service locators #20658

Closed

chalasr force-pushed the service-locator branch from 6b043d6 to 152b0af Compare February 7, 2017 08:57

chalasr force-pushed the service-locator branch from 152b0af to a0477bf Compare February 7, 2017 10:53

Taluu reviewed Feb 7, 2017

View reviewed changes

stof requested changes Feb 7, 2017

View reviewed changes

chalasr force-pushed the service-locator branch 5 times, most recently from 5a6a226 to b2b185f Compare February 7, 2017 19:15

nicolas-grekas added this to the 3.x milestone Feb 7, 2017

nicolas-grekas requested changes Feb 7, 2017

View reviewed changes

carsonbot added Status: Needs Work and removed Status: Needs Review labels Feb 7, 2017

chalasr force-pushed the service-locator branch from ab1e531 to 9718a65 Compare February 13, 2017 08:30

fabpot reviewed Feb 13, 2017

View reviewed changes

chalasr force-pushed the service-locator branch 2 times, most recently from bb455aa to 34443bb Compare February 13, 2017 09:47

nicolas-grekas reviewed Feb 13, 2017

View reviewed changes

chalasr force-pushed the service-locator branch 2 times, most recently from d4db8fc to 1c0c22d Compare February 13, 2017 10:02

[DI] Replace container injection by explicit service locators

e7935c0

[SecurityBundle] Avoid container injection in FirewallMap

chalasr force-pushed the service-locator branch from 1c0c22d to e7935c0 Compare February 13, 2017 10:05

fabpot merged commit e7935c0 into symfony:master Feb 13, 2017

chalasr deleted the service-locator branch February 14, 2017 15:43

chalasr mentioned this pull request Feb 15, 2017

Remove some container injections in favor of service locators #21625

Merged

hhamon mentioned this pull request Feb 20, 2017

[Form] allow form types + form type extensions + form type guessers to be private services #21690

Merged

nicolas-grekas modified the milestones: 3.x, 3.3 Mar 24, 2017

chalasr mentioned this pull request Apr 12, 2017

Introduce a PSR-11 handler locator thephpleague/tactician#111

Closed

fabpot mentioned this pull request May 1, 2017

Release v3.3.0-BETA1 #22603

Merged

lsmith77 mentioned this pull request Mar 4, 2018

make commands services FriendsOfSylius/SyliusImportExportPlugin#52

Closed

chalasr mentioned this pull request Jul 3, 2018

[DI] Add ServiceLocatorArgument to generate array-based locators optimized for OPcache shared memory #27783

Merged

[DI] Replace container injection by explicit service locators #21553

[DI] Replace container injection by explicit service locators #21553

Conversation

chalasr commented Feb 7, 2017 • edited Loading

ogizanagi commented Feb 7, 2017 • edited Loading

jvasseur commented Feb 7, 2017

chalasr commented Feb 7, 2017

stof commented Feb 7, 2017

ogizanagi commented Feb 7, 2017 • edited Loading

stof commented Feb 7, 2017

stof commented Feb 7, 2017

chalasr commented Feb 7, 2017

ogizanagi commented Feb 7, 2017

chalasr commented Feb 7, 2017

Taluu Feb 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chalasr Feb 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chalasr Feb 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chalasr Feb 7, 2017 • edited Loading

Choose a reason for hiding this comment

jvasseur Feb 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas commented Feb 7, 2017 • edited Loading

chalasr commented Feb 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chalasr Feb 13, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fabpot commented Feb 13, 2017

lsmith77 commented Feb 14, 2017

chalasr commented Feb 14, 2017

chalasr commented Feb 7, 2017 •

edited

Loading

ogizanagi commented Feb 7, 2017 •

edited

Loading

ogizanagi commented Feb 7, 2017 •

edited

Loading

Taluu Feb 7, 2017 •

edited

Loading

chalasr Feb 7, 2017 •

edited

Loading

chalasr Feb 7, 2017 •

edited

Loading

chalasr Feb 7, 2017 •

edited

Loading

jvasseur Feb 7, 2017 •

edited

Loading

nicolas-grekas commented Feb 7, 2017 •

edited

Loading

chalasr Feb 13, 2017 •

edited

Loading