[DependencyInjection] Allow for synthetic services before compilation #19619
Conversation
| @@ -52,6 +52,10 @@ public function process(ContainerBuilder $container) | |||
| $tmpContainer->addExpressionLanguageProvider($provider); | |||
| } | |||
|
|
|||
| foreach ($container->getSynthetics() as $id => $service) { | |||
| $tmpContainer->set($id, $service); | |||
There was a problem hiding this comment.
Concerning BC: all services set via PrependExtensionInterface::prepend are now available while extension loading. Or any other service available at this point.
The services set while loading are not merged back into the container, this is perhaps considerable.
|
@Ener-Getick : My PR was only removing "dead code". It doesn't un-deprecate getting a service instance from the But I'm not convinced we need something like the new |
|
Most important is the logic of
edit: @Ener-Getick i can rebase.. :) |
|
@ogizanagi the So if you have a non-synthetic definition + the ready to use service, you are stuck now. Not sure how common that is, on the other hand #19606 is poc of exactly that. |
|
@ro0NL : My point is that you probably don't need having a service definition for services designed to be used during the container building time only (but is it even a good idea to depend on any kind of service in this phase ?). :/ Thus my suggestion about exposing a EDIT:
As you said, not sure there are real use cases for this. Why would you need a container to build a service you're able to build yourself and would not be used at runtime ? Eventually you only need a way to share things during compilation time. |
|
Could be.. this is just a generic approach that allows for it. If the component really needs it, i dont know. Perhaps nice to have. But yeah, my usecase is definitely kernel+bundles ;-) A |
|
@ro0NL : regarding the part I've added after editing my comment above, here is a naive & straightforward implementation of a contextualized container builder, allowing to share some context during the build time, before compilation of the container: master...ogizanagi:contextualized_container Here, the Of course, I don't expect this to be a perfect nor legit implementation, but simply exploring and giving more hints on how to proceed considering your uses cases. :) |
|
@ogizanagi im thinking this thru.. maybe you're right on how we try to solve this and not being the right direction. It feels workaroundish i guess.
I was also heading "context" way, and just had a crazy idea: |
Indeed, it should not. I guess it was part of the idea behind the
Yeah...thought about that too, but I'm not fan of giving visibility to the fact we use a container to build a container... 😅 At least the foolish lockable |
|
I dont mind :) I think we're too much used to one container being the almighty thing. It's a pattern, eventually it's legit 😉 Another, bridge too far, idea; each bundle defines it's own container(s) in the ecosystem. Container as a service 😱 Anyway, maybe focus this PR on deprecating |
IMHO it should be the subject of another PR deprecating the whole |
Separated from #19606
This allows accessing synthetic services from
ContainerBuilder::getbefore compilation, besides they are exposed while extension loading.It covers 2 usecases;
ServiceAwareDefinitionwhich covers both usecases as well)