Make as many services private as possible #23867
Conversation
|
ive added a temp. pass for 3.4 that automates the approach, so we can do all at once and create a single legacy service locator. |
|
What about using a tag? (eg "deprecated.public"?) Note that we use a similar pattern in |
|
A tag wont work for aliases right... so it needs to be based on a list of id's i guess. Either way; this PR seeked for a lazy plan :) but i could give it a try soonish. Still.. for services that we might want to rename anyway this approach is simple and effective. The proposed feature would be to preserve the id and trigger a custom deprecation message when accessed with get() IIUC. |
|
Quick update after a little discussion with @nicolas-grekas
It works; yet there's no deprecation triggered from |
|
Well, having no support for such migration path in Symfony 4 makes it unusable for bundles: they cannot switch their services to be private if they need to support Symfony < 3.3 requiring many services to be public. Most bundles won't be able to require Symfony 3.3+ (or even worse 3.4+ for some cases) before the release of 4.0, due to the 2.8 LTS (unless they say that people using 2.8 LTS have to use old releases and give up on bug fixes of the bundle, which may not be fine). Cases requiring 3.4+ are even totally impossible, as 4.0 will be released at the same time. |
|
What about this plan:
That would allow bundles to still have the services public with <3.3, trigger the deprecation with 3.4, and have the services really private when used with 4.0. (I'm still trying to not have to create and maintain a feature to move from pub 8000 lic to private on the long term) |
|
@nicolas-grekas that looks good |
|
Just some thoughts: The whole concept of private services is only to shrink the container. So basically it's just implementation detail and ideally as developer I should not need to care about this. Can't we achieve that goal? Now that the container creates files per factory, the container should scale better with the amout of services, right? Can't we improve that even more so that the overhead per service is negligible? E.g. less internal tracking of serivce ID mapping to file name/method name. |
|
I think the only difference are inlined services. If we'd say everything is public, there is no private anymore, the container would need to keep a reference to the inlined services. But does this really matter? |
|
I like @Tobion thoughts a lot :) |
|
In Flex, we made the move of loading everything in the |
Proof of concept for a config only approach to upgrade services from public to private. Perfect chance to go with class named services, where possible.
Perhaps, to ease things, we can automate this behavior so in an extension you can do
ContainerBuilder::expose(['new_id' => 'old_id'])for example, but i wouldnt make it to big a feature.Thoughts?