[DependencyInjection] Anonymous services in PHP DSL #24632

unkind · 2017-10-19T17:54:07Z

Q	A
Branch?	4.1
Bug fix?	no
New feature?	enhancement for fluent PHP configs
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#24493
License	MIT
Doc PR	not yet

See #24493:

$s->anonymous(SendEmailForRegisteredUser::class)->tag('listener');

unkind · 2017-10-19T17:56:28Z

I didn't fix all the tests yet (is there any script to update all autogenerated DI-fixtures?), need feedback. ping @nicolas-grekas

UPD: target branch is incorrect. Anyway, any chance to merge it in 3.4? If so, I'll reopen PR.

nicolas-grekas

I think I'm 👎: this will introduce a non trivial amount of complexity (it's broken already), when the current way just works (just give that decorator a name.)

nicolas-grekas · 2017-10-19T21:50:00Z

src/Symfony/Component/DependencyInjection/Loader/Configurator/Traits/ArgumentTrait.php

@@ -22,6 +30,25 @@
     */
    final public function args(array $arguments)
    {
+        $arguments = array_map(


Ihe inner can be injected anywhere, not only in the constructor, and can be nested also. The logic should be in AbstractConfigurator::processValue() (but it's not trivial to do so).

and can be nested also

What do you mean?

The logic should be in AbstractConfigurator::processValue() (but it's not trivial to do so)

It is still in dev branch, later will be much harder to fix it. Probably, it's not the only case when we need Definition object there.

the inner service doesn't have to be injected as an argument: it can be nested in an array, which itself is passed as argument (constructor, or setter, or property in fact.)

the inner service doesn't have to be injected as an argument: it can be nested in an array, which itself is passed as argument (constructor, or setter, or property in fact.)

It just requires to tweak AbstractConfigurator::processValue() to make it work, doesn't it?

it should (but I'm still not sure it's worth the added complexity)

It there any reason why it is static? As I can see, AbstractConfigurator contains link to the definition. I'm not big fan of it, but it's cheap solution.

it's used in function iterator(array $values)

nicolas-grekas · 2017-10-19T21:50:23Z

src/Symfony/Component/DependencyInjection/Loader/Configurator/Traits/ArgumentTrait.php

+                        );
+                    }
+
+                    return new ReferenceConfigurator($decorated[1] ? $decorated[1] : $this->id . '.inner');


".inner" is not hardcoded when decorating services, see "renamedId".

I don't get it. $decorated[1] contains value of renamedId. I use .inner suffix when user didn't specify renamedId.

unkind · 2017-10-19T22:04:48Z

I think I'm 👎: this will introduce a non trivial amount of complexity (it's broken already), when the current way just works (just give that decorator a name.)

What about just anonymous services without decorators?

nicolas-grekas · 2017-10-19T22:18:01Z

What about just anonymous services without decorators?

I would do it without the "anonymous" helper: ->set(null, Fqcn::class)

unkind · 2017-10-19T22:31:24Z

I would do it without the "anonymous" helper

Well, a lot (probably, most) of my services are anonymous: listeners, command handlers, API controllers, console commands, cache/monitoring/logging decorators. I can use set(SendEmailForRegisteredUserListener::class, ...) for most of them, but they include namespace and service name becomes very long. On other hand, typing set(null, ...) again and again doesn't make me happy as well.

nicolas-grekas · 2017-10-19T22:50:16Z

My fear is that ppl will get confused when reading
->set(Foo::class)
vs
->anonymous(Foo::class)
the difference is not obvious if you're not used to anonymous services (how many of us are, of many new comers...)
->set(null, Foo::class) on the contrary is "more" different than ->set(Foo::class)

And I'm also fearing that writing actually might become more confusing: "anonymous" would become a new item on the autocompletion list, which ppl might have a hard time figure out what it means (because it's not that common) - and even scarier: ppl doing the mistake of selecting the wrong set/anonymous choice might have an even harder time figuring out their mistake.

unkind · 2017-10-19T23:10:25Z

the difference is not obvious if you're not used to anonymous services
And I'm also fearing that writing actually might become more confusing

Let them learn the difference. They won't hurt themselves, it's not a gun.

(how many of us are, of many new comers...)

I think most of us have such services in our codebases, we probably just don't realize it. It's yet another reason to make it explicit in my opinion.

unkind · 2017-10-20T21:05:29Z

I've removed decorators, tests are OK except some unrelated ones.

Let's focus on the anonymous() helper. Do you really want to remove it? I'd like to see it as explicit way to register a service, I really don't like nullables, it's almost always better to introduce new straightforward method. I also really doubt it's sort of "forbidden knowledge" that may bring any problems to people. They'd rather discover something new for themselves.

unkind · 2017-10-20T21:28:49Z

Offtopic:

just give that decorator a name

This annoys in the same way as requirement to specify name for "anonymous" services: I don't need it. Considering we have name convention for service names like game.infrastructure.players_qs_memcache_decorator.inner, it becomes a problem. We also have sometimes 3-4 similar services with decorators, so I copy-paste definitions and trying to find the difference in names which I don't even need, ugh.

nicolas-grekas · 2017-11-26T19:46:25Z

I'm still really unsold on the topic, if anything, ->set(null, Foo::class) should be the way to IMHO.
Services don't have to be anonymous. Giving them a name is fine (esp. when the name is automatically set as is now.)

unkind · 2017-11-26T20:05:35Z

@nicolas-grekas it looks like a straw man for me: I didn't say that services have to be anonymous. Just many of them could be. Giving name is fine, but sometimes is totally pointless like rituals.

->set(null, Foo::class)

Giving a name for this construction is fine, isn't it? ->set(null, Foo::class) is WTF syntax and it's harder to google it.

The whole discussion is about explicit vs implicit syntax for the same concept. I don't understand your point why this kind of syntax should be implicit.

nicolas-grekas · 2017-11-26T20:16:06Z

Oh! :)
could be would need a reason. When doing ->set(Foo::class) is actually fine, I really don't see benefit of doing ->anonymous(Foo::class). The first providing a name is a side effect that benefits everyone when needing a name, and doesn't hurt anyone when a name is actually not needed. That's my reasoning. Just let SF give a name for you, and ignore it if you don't need it.
The only case where the name is actually boilerplate if when you need several services implemented by the same class. Which is a case where you have to type some configuration anyway, and doing ->set(null, Foo::class) would just work and not look like impossible boilerplate IMHO.

unkind · 2017-12-18T02:28:34Z

It should be quite easy to define your own DSL, by creating a different set of configurator classes, and type-hinting for them in the closure.

What do you think of decorators for ContainerConfigurator?

@@ -23,6 +25,16 @@ use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigura
  */
 class PhpFileLoader extends FileLoader
 {
+    private $configuratorDecorator;
+
+    public static function withConfiguratorDecorator(ContainerBuilder $container, FileLocatorInterface $locator, callable $configuratorDecorator): PhpFileLoader
+    {
+        $loader = new self($container, $locator);
+        $loader->configuratorDecorator = $configuratorDecorator;
+
+        return $loader;
+    }
+
     /**
      * {@inheritdoc}
      */
@@ -44,7 +56,13 @@ class PhpFileLoader extends FileLoader
         $callback = $load($path);

         if ($callback instanceof \Closure) {
-            $callback(new ContainerConfigurator($this->container, $this, $this->instanceof, $path, $resource), $this->container, $this);
+            $configurator = new ContainerConfigurator($this->container, $this, $this->instanceof, $path, $resource);
+
+            if ($this->configuratorDecorator) {
+                $configurator = call_user_func($this->configuratorDecorator, $configurator);
+            }
+
+            $callback($configurator, $this->container, $this);
         }

ro0NL · 2017-12-28T18:25:11Z

set(null, Foo::class) doesnt work in 4.0 due string $id type :) which is also the phpdoc in 3.4, this is actually consistent with the current loaders right.

Anyway, just walked into this trying to register a event listener twice. Now in a codebase full of set(Fqcn::class) the set(null, Fqcn::class) (if it worked) looks a bit odd... but im really thinking of a good ID value now 🤔 (the "naming is hard" issue also counts a bit IMHO).

unkind · 2017-12-28T19:01:20Z

naming is hard

Especially when you don't need a name (anonymous/lambda functions is a very close example).

nicolas-grekas · 2017-12-29T10:35:43Z

set(null, Foo::class) doesnt work in 4.0 due string $id type

which is not an issue since the method is final, so can be changed without any BC break

ro0NL · 2017-12-29T10:46:40Z

Hm looking at failing tests locally

+    :\n
+        class: App\BarService\n
+        public: true\n

that's bad right? :)

unkind · 2017-12-29T11:11:10Z

@ro0NL if you mean my branch, it's possible if you merged with 3.4/master because ContainerBuilderTest was changed (GitHub shows the conflict). I could resolve it, but I don't understand the state of PR.

Do I understand correctly that in order to merge it I have to replace ->anonymous() with ->set(null, ...)?

ro0NL · 2017-12-29T11:13:11Z

right. I tested on 3.4 :) i thought it worked today already. If we can settle with set(null, Fqcn::class) im fine 👍

unkind · 2018-01-04T00:41:05Z

@nicolas-grekas can you change base branch on master?

curry684 · 2018-01-04T01:19:24Z

You can do it yourself with the edit button at the top of the issue.

unkind · 2018-01-04T01:32:30Z

@curry684 thanks, didn't know it.

nicolas-grekas

(@unlinkd FYI, I pushed some changes on your fork, was quicker for me this way. Ready on my side thank you.)

unkind · 2018-01-22T20:24:31Z

OK, looks good.

fabpot · 2018-01-23T06:32:10Z

Cannot be merged as tests are broken.

nicolas-grekas · 2018-01-23T06:59:20Z

Tests fixed, should be green in a few minutes.

fabpot · 2018-01-23T07:22:46Z

Thank you @unkind.

…nkind) This PR was merged into the 4.1-dev branch. Discussion ---------- [DependencyInjection] Anonymous services in PHP DSL | Q | A | ------------- | --- | Branch? | 4.1 | Bug fix? | no | New feature? | enhancement for fluent PHP configs | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #24493 | License | MIT | Doc PR | not yet See #24493: ```php $s->anonymous(SendEmailForRegisteredUser::class)->tag('listener'); ``` Commits ------- ee42276 [DI] Add way to register service with implicit name using the PHP DSL

ro0NL · 2018-01-23T07:26:43Z

Nice one @unkind. Thx super useful :)

carsonbot added Status: Needs Review DependencyInjection labels Oct 19, 2017

unkind force-pushed the enhancement-anonymous-services-fluent-php branch 7 times, most recently from 55997aa to 02bf763 Compare October 19, 2017 18:08

nicolas-grekas added this to the 3.4 milestone Oct 19, 2017

chalasr changed the base branch from master to 3.4 October 19, 2017 19:26

unkind changed the title ~~[DependencyInjection] Anonymous services & decorates()~~ [DependencyInjection] Anonymous services & decorators Oct 19, 2017

nicolas-grekas reviewed Oct 19, 2017

View reviewed changes

unkind force-pushed the enhancement-anonymous-services-fluent-php branch 3 times, most recently from f304759 to 766ceb3 Compare October 20, 2017 20:46

unkind changed the title ~~[DependencyInjection] Anonymous services & decorators~~ [DependencyInjection] Anonymous services Oct 20, 2017

nicolas-grekas modified the milestones: 3.4, 4.1 Oct 21, 2017

unkind mentioned this pull request Dec 30, 2017

[RFC] [DependencyInjection] Custom container configurators (fluent PHP format) #25630

Closed

unkind force-pushed the enhancement-anonymous-services-fluent-php branch from 766ceb3 to d709412 Compare January 4, 2018 00:39

unkind changed the base branch from 3.4 to master January 4, 2018 01:31

nicolas-grekas force-pushed the enhancement-anonymous-services-fluent-php branch from d709412 to 8b6945d Compare January 22, 2018 19:30

nicolas-grekas changed the title ~~[DependencyInjection] Anonymous services~~ [DependencyInjection] Anonymous services in PHP DSL Jan 22, 2018

nicolas-grekas force-pushed the enhancement-anonymous-services-fluent-php branch from 8b6945d to 2348c11 Compare January 22, 2018 19:32

nicolas-grekas approved these changes Jan 22, 2018

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Review labels Jan 22, 2018

fabpot approved these changes Jan 23, 2018

View reviewed changes

[DI] Add way to register service with implicit name using the PHP DSL

ee42276

nicolas-grekas force-pushed the enhancement-anonymous-services-fluent-php branch from 2348c11 to ee42276 Compare January 23, 2018 06:58

fabpot merged commit ee42276 into symfony:master Jan 23, 2018

fabpot mentioned this pull request May 7, 2018

Release v4.1.0-BETA1 #27181

Merged

[DependencyInjection] Anonymous services in PHP DSL #24632

[DependencyInjection] Anonymous services in PHP DSL #24632

Conversation

unkind commented Oct 19, 2017 • edited

unkind commented Oct 19, 2017 • edited

nicolas-grekas left a comment • edited

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

unkind Oct 19, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unkind commented Oct 19, 2017

nicolas-grekas commented Oct 19, 2017

unkind commented Oct 19, 2017

nicolas-grekas commented Oct 19, 2017 • edited

unkind commented Oct 19, 2017

unkind commented Oct 20, 2017

unkind commented Oct 20, 2017 • edited

nicolas-grekas commented Nov 26, 2017

unkind commented Nov 26, 2017

nicolas-grekas commented Nov 26, 2017 • edited

unkind commented Dec 18, 2017

ro0NL commented Dec 28, 2017

unkind commented Dec 28, 2017

nicolas-grekas commented Dec 29, 2017 • edited

ro0NL commented Dec 29, 2017

unkind commented Dec 29, 2017

ro0NL commented Dec 29, 2017

unkind commented Jan 4, 2018

curry684 commented Jan 4, 2018

unkind commented Jan 4, 2018

nicolas-grekas left a comment

Choose a reason for hiding this comment

unkind commented Jan 22, 2018

fabpot commented Jan 23, 2018

nicolas-grekas commented Jan 23, 2018

fabpot commented Jan 23, 2018

ro0NL commented Jan 23, 2018

unkind commented Oct 19, 2017 •

edited

unkind commented Oct 19, 2017 •

edited

nicolas-grekas left a comment •

edited

unkind Oct 19, 2017 •

edited

nicolas-grekas commented Oct 19, 2017 •

edited

unkind commented Oct 20, 2017 •

edited

nicolas-grekas commented Nov 26, 2017 •

edited

nicolas-grekas commented Dec 29, 2017 •

edited