-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DI] Deprecate Container::isFrozen and introduce isCompiled #19673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
In some ways it was actually compiling (resolving the parameters), as this is also done in a compiler pass. So we can also just go with
|
-1 for renaming compile to freeze. This method is not only about freezing. It is about performing all the compilation steps of the container building (everything done in compiler passes for instance). |
@stof different approach. WDYT? |
I don't understand the problem you are trying to fix here. Can you elaborate? Deprecating something should be taken lightly, so we need to have a very good reason to rename something. |
It's confusing to mix&match This exposes a minor code smell in |
* @return bool true if the container parameter bag are frozen, false otherwise | ||
* @return bool | ||
*/ | ||
final public function isCompiled() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now the ought to use method. If you truly want to check for a frozen parameter bag use
getParameterBag() instanceof FrozenParameterBag
instead (hence the deprecation).
Besides, this method now guarantees state of compile()
as we dont depend on a frozen parameterbag for that anymore (which we can pass to the constructor ;-)).
Now.., i assume the calls to isFrozen
in ContainerBuilder
(or practically anywhere) are intended as isCompilated
. Which is my true point :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why making it final? That would be the first method in the class.
if ($this->isFrozen()) { | ||
throw new BadMethodCallException('Cannot load from an extension on a frozen container.'); | ||
if ($this->isCompiled()) { | ||
throw new BadMethodCallException('Cannot load from an extension on a conpiled container.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
compiled
I tend to be sympathetic to deprecating the "frozen" vocabulary on containers. It's been looking strange to me also and the difference is unclear with the "compile" concept. |
Updated the What do we expect when dumping this uncompiled (ie. we dont call |
@ro0NL : As we do not rely anymore on the |
$this->parameterBag->resolve(); | ||
|
||
$this->parameterBag = new FrozenParameterBag($this->parameterBag->all()); | ||
if (!$this->parameterBag instanceof FrozenParameterBag) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be removed: changing the object instance of the bag can be seen as a wanted side effect of compiling. Not wrapping a FrozenParameterBag in a FrozenParameterBag looks like an unnecessary optimization to me also.
@ogizanagi merging is only allowed before compiling. If you passed a Not sure what's best for DX here.. crashing or ignoring silently... @nicolas-grekas any thoughts? Other then that.. this is ready. |
Oh and btw... just to be sure; the YAML+XML dumper really depend on a frozen bag right? Due escaping. |
Rebase needed to take #19704 into account. |
@ro0NL as far as i can see isCompiled will return false for dumped container whether or not container was compiled beforehand |
I really don't know if this has a chance to be accepted by the core team, but let's say yes, I think we should go one step further and try deprecating dumping non-compiled containers. |
@allflame
|
@ro0NL I'm aware of that fact. Let me explain using your own statements: |
Rebased. Still all good :) |
I just realized i made a mistake with the latest deprecation: ed5b1d8#diff-f7b23d463cba27ac5e4cb677f2be7623R76 Im talking uncompiled container here, looking at the class it should have been not-frozen container. I really dont mind this tiny semantic. Then again, if we dont do the PR it might be worth updating that instead... sorry :) |
$this->parameterBag = new FrozenParameterBag($this->parameterBag->all()); | ||
|
||
$this->compiled = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd keep only this line a revert the previous changes in this method, that would prevent any potential BC-related side effect of the change.
* @return bool true if the container parameter bag are frozen, false otherwise | ||
*/ | ||
public function isFrozen() | ||
{ | ||
@trigger_error(sprintf('The %s() method is deprecated as of 3.3 and will be removed in 4.0. Use the isCompiled() method instead.', __METHOD__), E_USER_DEPRECATED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we use "since version 3.3" here usually I think
@@ -554,6 +554,10 @@ public function prependExtensionConfig($name, array $config) | |||
*/ | |||
public function compile() | |||
{ | |||
if ($this->isCompiled()) { | |||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's remove this change, it just opens a potential BC break to me
👍 with suggested changes |
Updated, rebased & waiting for travis. Cant wait for 4.0 guys 👍 |
@ro0NL Looks like tests fail. |
Hm.. looks fixture related, maybe something added in the meanwhile. Ill have a look tonight. Note to self;
|
ping @ro0NL |
Yes.. ill check it tonight. Focussed on #19668 first.. but that's more or less dealt with now. |
All good @nicolas-grekas |
LGMT @ro0NL Can you rebase one last time? Thanks. |
@fabpot all good. |
Thank you @ro0NL. |
…piled (ro0NL) This PR was merged into the 3.3-dev branch. Discussion ---------- [DI] Deprecate Container::isFrozen and introduce isCompiled | Q | A | | --- | --- | | Branch? | "master" | | Bug fix? | no | | New feature? | yes | | BC breaks? | no | | Deprecations? | yes | | Tests pass? | yes | | Fixed tickets | comma-separated list of tickets fixed by the PR, if any | | License | MIT | | Doc PR | reference to the documentation PR, if any | This deprecates the concept of freezing a container, implied by `Container::isFrozen`. However, freezing happens due compilation (`Container::compile`). So having just `isCompiled` instead seems more intuitive, and plays along well with `ContainerBuilder`. Before/After; - `Container::isFrozen` - Checks if the parameter bag is frozen, but is deprecated in 3.2 - In 4.0 this methods does not exists and can be replaced with `getParameterBag() instanceof FrozenParameterBag` _or_ `isCompiled()`. Depending on what you want (to clarify; the behavior is different when passing a frozen bag to the constructor) - `Container::isCompiled` - Truly checks if `compile()` has ran, and is a new feature - `ContainerBuilder::merge` etc. - Now uses `isCompiled` instead of `isFrozen`, ie. we allow for it till compilation regarding the state of the paramater bag Commits ------- 6abd312 [DI] Deprecate Container::isFrozen and introduce isCompiled
*/ | ||
public function set($id, $service) | ||
{ | ||
$id = $this->normalizeId($id); | ||
|
||
if ($this->isFrozen() && (isset($this->definitions[$id]) && !$this->definitions[$id]->isSynthetic())) { | ||
if ($this->isCompiled() && (isset($this->definitions[$id]) && !$this->definitions[$id]->isSynthetic())) { | ||
// setting a synthetic service on a frozen container is alright | ||
throw new BadMethodCallException(sprintf('Setting service "%s" for an unknown or non-synthetic service definition on a frozen container is not allowed.', $id)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sprintf('Setting service "%s" for an unknown or non-synthetic service definition on a compiled container is not allowed.', $id)
basically, s/frozen/compiled
, no ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😭
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with #22112
This PR was squashed before being merged into the 4.0-dev branch (closes #22763). Discussion ---------- [DI] Remove deprecated isFrozen() | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | yes | Deprecations? | no | Tests pass? | should be | Fixed tickets | #... <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | symfony/symfony-docs#... <!--highly recommended for new features--> See #19673 Test failure seems unrelated. Commits ------- 04b39a3 [DI] Remove deprecated isFrozen()
This deprecates the concept of freezing a container, implied by
Container::isFrozen
. However, freezing happens due compilation (Container::compile
). So having justisCompiled
instead seems more intuitive, and plays along well withContainerBuilder
.Before/After;
Container::isFrozen
getParameterBag() instanceof FrozenParameterBag
orisCompiled()
. Depending on what you want (to clarify; the behavior is different when passing a frozen bag to the constructor)Container::isCompiled
compile()
has ran, and is a new featureContainerBuilder::merge
etc.isCompiled
instead ofisFrozen
, ie. we allow for it till compilation regarding the state of the paramater bag