[RFC] Making services private by default in Symfony 4?

[nicolas-grekas]

Just wondering, how about making services private by default in Symfony 4?
That would give us more private services optimizations by default, thus lighter containers.
The path could be as "simple" as deprecating the "public" attribute and replacing it by a "private" one.
Worth pursuing?

[GuilhemN]

👍 but for that imo we have to allow using private services with any tag (create a public alias when needed for example).

[linaori]

I'd be very happy to see this, but it would be a big issue for people extending the Controller. Imo Controller as a Service is the way to go but not everyone agrees with me.

[GuilhemN]

@iltar imo symfony should create its own public aliases when it needs to, instead of forcing the user to make his services public... but i'm not sure everyone agrees.

Edit: actually that looks hard to do for controllers as they are resolved at runtime...

[linaori]

@Ener-Getick the problem is that Symfony can't guess the service you're going to need if you use a Service Locator.

[GuilhemN]

An alternative would be to encourage using DunglasActionBundle but again not everyone agrees...
We could limit the problem by allowing making public an entire set of services (during their import or as a header of the file).

[linaori]

You'd have to do static code analysis of the file and try to determine all locator calls. This works up to a point where calls become dynamic.

[GuilhemN]

@iltar i meant as a header of the config files 😉

[linaori]

Ah, well then I would rather recommend making everything private by default and recommending controller as a service instead.

[hhamon]

I would vote for but that's a major BC break and it will probably prevent people from upgrading to Symfony 4. I don't know if we can make this behavior globally configurable (enable or disable).

[GuilhemN]

@hhamon that's why we use bc layers and deprecations. For apps respecting best practices, it shouldn't be that hard to upgrade.

But i'm wondering if it wouldn't make services even harder to understand for newcomers. I'm 👍 for making this globally configurable.
Maybe we should make services public by default in the standard edition and private by default in the framework to ensure bundles tests are always against the worst scenario. This would make easier to understand the framework using the standard edition but that wouldn't be very consistent.

[hhamon]

Yes it will be harder for newcomers to understand this concept. When I do training sessions, including advanced ones, it's often rare that people know the differences between private and public services. And the consequences private service definitions have on the container compilation. So IMO, we have to be careful with this. If we decide to switch to private services by default, it has to be very very well documented. But again, I would prefer having a global configuration setting to enable or disable this behavior.

[GuilhemN]

@hhamon for me, we should promote autowiring for newcomers (or at worst methods hiding the calls to the container such as the base Controller). It is more magic but it reduces the learning path and would allow us more easily to do this change.

[nicolas-grekas]

It can't be a global flag: definitions can't rely on some outside context! But it could be changed locally for a whole file for sure. Having everything private by default would prevent using the dic as a service locator, which is too easy for newcomers today. They'd better learn very soon that if they do this, they must optin to the not-the-best practice.

[nicolas-grekas]

Oh btw, we already planned to prevent fetching private services from the container in 4.0, so we already have the right explanation point for newcomers: the exception message they'll get then.