[RFC][DependencyInjection][HttpKernel] Kernel as a service #19606
Conversation
|
What about instead removing the concept of obsolete definitions ? Imo it could be considered as a bug fix as this behavior is clearly not expected. |
|
Marking a definition as obsolete when the same id is overwritten by a synthetic service object sounds logical to me. I think the "problem" is a synthetic service needs to be tight to a definition id... im not sure we wanna change that, i guess this is by design. But yeah, setting the kernel instance along with a synthetic definition, in early phase could work also for feature 2, now that i think of it. However feature 1 for would still be useful as it allows for non-synthetic definitions + service object to be set. edit: Btw.. it becomes real quirky in edit2: yeah extensions are still an issue 😭 |
| $container = $this->buildContainer(); | ||
| $container->setDefinition('kernel_as_a_service', $serviceDefinition); |
There was a problem hiding this comment.
edit: Btw.. it becomes real quirky in MergeExtensionConfigurationPass (see my first attempt) where synthetic services are vanished anyway during extension loading ;-)
— #19606 (comment)
If you want to use this service in an extension, you'll still have to do quirky things in MergeExtensionConfigurationPass as in your first attempt to make it available in the $tmpContainer passed to the ExtensionInterface::load method, right ?
Or perhaps you're only targeting compiler passes now ?
There was a problem hiding this comment.
Working on it ;-)... however there are some design choices to be made.
| } catch (ServiceNotFoundException $e) { | ||
| if (ContainerInterface::EXCEPTION_ON_INVALID_REFERENCE !== $invalidBehavior) { | ||
| return; | ||
| if ($this->compiled && ContainerInterface::EXCEPTION_ON_INVALID_REFERENCE === $invalidBehavior) { |
There was a problem hiding this comment.
For BC, however i tend to debug unknown id's before state. Just throwing here would be fine by me.
|
This is also highly related to #19192 i guess. |
|
Favoring #19646 |
TLDR; This allows for ready to use service objects during container compilation~~.~~, and now also extension loading.
How i did it;
After my first attempt i think i got a viable solution now that allows to work with safe service objects during container compilation, basically it introduces a
ServiceAwareDefinition; a service definition aware of its service object, which is allowed for inContainerBuilder::get. It's bulletproof, in a way it's developer responsibility to keep the definition+service in sync. This also plays well with synthetic services perhaps...This is feature 1, which can be a separate PR. Feature 2 is introducing the kernel as a service (aware definition). For now i think it's good mainly because of pragmatic reasons; we can fix bugs in a normal way. In the long run it allows for separation of concerns; kernel/bundles in the ecosystem (booting, building, terminating) and kernel/bundles in userland (paths, names, utility).
The second concept is far from ready, but what about this approach?