[DI] Deprecate ContainerBuilder::set #19644
Conversation
|
This somewhat limits the I guess, if we technically want the |
| @@ -401,20 +403,20 @@ public function has($id) | |||
| */ | |||
| public function get($id, $invalidBehavior = ContainerInterface::EXCEPTION_ON_INVALID_REFERENCE) | |||
| { | |||
| $id = strtolower($id); | |||
There was a problem hiding this comment.
Why moving those lines up ?
There was a problem hiding this comment.
Currently you get a deprecation error for each possible alias (by the looks of the code 👼), so i tend to resolve aliases first and then logic of get. Consider it an early return.
Ill dig into this to expose the side effects.
|
In my opinion, the builder should not be the container. Right now building the container and using the container is overlapping the same functionality. I think it would be in the best interest to have the Builder build it only. |
|
I think we need to respect However, we can make a design choice here;
|
|
I think it should behaves like a |
|
@ogizanagi tests are not easy to fix. Mostly due aliases.. Try and fix the deprecation for |
|
See #19708 |
Currently the behavior for synthetic services and the container builder is unclear;
set()is always allowed (when mapped to a defintion)get()is disallowed, but only before compilation (we ignore a potential synthetic service being validly available at this point)This lead to some discussion in #19619
IMO there are 2 acceptable/consistent solutions, either disallow
setfully/before compilation, or allowgetfor synthetic services at all time. This reflects simpleset/getbehavior.Deprecating
setbefore compilation would make it clear theContainerBuilderonly works as asContainerafter compilation. Ie. you'd still have best of both.