[DI] Public, private and hidden services #27293
Comments
|
So if I understand the proposal correctly, using |
|
Private services were never about internal services, even in 2.0.0. You were always able to inject them in your own services, in any way you want.
That's actually something done later in the Symfony history, and not at all the reason to introduce private services.
that's totally wrong. Their id is not randomized at all. They get excluded from the map of available services when dumping (and their instances are stored in a separate map internally, but using their actual id). |
|
I think the issue is the naming of this concept. A private service is not restricted to a single bundle (there is no such concept, as they all share the same container). It is private to the container (only the container can get the instance to use it elsewhere, but your own code cannot). I think What we could do is rename |
|
|
|
and your own vision of "private services" still does not correspond to what @nicolas-grekas wants to build with hidden services, because the "hidden" state is tied to the identifier, not to the service definition (so works also for identifiers being used by aliases, keeps working if you override the service definition for an identifier, etc...). |
|
@stof regarding the random service IDs, I was referring to PRs like #19683, and comments like this: #19117 (comment) In any case, I still think that "public" (you can use this) and "private" (don't use these services; they are for internal purposes) would be easier to understand that "public" (don't use this; all private by default), "private" (but not really private/internal, you can use them almost as public) and "hidden" (which are hidden in some places, but you can still use them, like a public/private service). |
|
@javiereguiluz there is a difference between |
and this is actually a requirement of the DI design pattern: being able to rewire things as you want. There is no such things as "private wiring", bundle or not. The original description uses the same words "private/public" for very different and unrelated concepts. The already started story is to split services in 3 groups:
All in all, this issue is a duplicate. |
|
I'm closing this issue as Nicolas asked. I also closed the other issue too (#27284) although it had 67 upvotes and zero downvotes 😢 |
@nicolas-grekas Still, they can be hidden by configuration, not by convention. If bundles want to hide internal services to not make noise for developer, why should they use special dot notation instead of configuring them with |
|
Because IMHO it makes no sense to significantly increase the complexity of the code base to handle this concern while the current solution fits very simply and naturally the existing code. And also as I said in the linked issue, conceptually this doesn't belong to dependency injection configuration. BUT let it be clear: if anyone disagrees enough to make a PR and prove its points then fine. I'm "just" the implementer of the current system and it deserved some explanations, which are not only in my head now, so that this can be challenged more easily. |
Uh oh!
There was an error while loading. Please reload this page.
Description
In the past, services were public or private (I'm ignoring "synthetic" services and other edge cases):
$this->get()them in controllers.$this->get()because they have random service IDs.Also, private services don't appear on
debug:container. It makes sense.Problem
In recent Symfony versions we made all services private by default. In my opinion, the problem is that we don't really want to make services private. In fact, those services are used in your app, so their "nature" is to be public. We make them private so you can't do
$this->get()to get them (and to unlock some performance improvements).Proposal
What if we do this:
$this->get()in controllers and commands and force to always inject services. This is a BC break, only possible in Symfony 5.debug:containerThe text was updated successfully, but these errors were encountered: