-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DependencyInjection] Use a service locator in AddConstraintValidatorsPass #21730
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
@@ -11,7 +11,7 @@ | |||
|
|||
namespace Symfony\Bundle\FrameworkBundle\Validator; | |||
|
|||
use Symfony\Component\DependencyInjection\ContainerInterface; | |||
use Psr\Container\ContainerInterface; |
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.
Given $container is protected I think that's a BC break
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 think it's acceptable, the methods defined are the same and it will only fail if someone checks its interface which is unlikely.
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.
Not sure. ContainerInterface contains more methods than the Psr one, calling $this->container->getParameter()
would break. We had to write a BC layer for a similar case in #21451
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.
Note also that adding deprecations for using experimental features has been rejected in #21625. I would wait for 4.0 on this one (that's why I did not proposed it), let's see what other think.
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.
about deprecating in this PR, see #21625 (comment)
this needs to be resolved before acting to me.
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've an idea of a BC layer (including deprecations but not about experimental features), I'll update the pr soon.
Considering your comment, I think it's better to delay this change to 4.0 and to just deprecate |
e2f0107
to
9ccdeac
Compare
Is there any BC break really? |
If someone uses |
BC breaks are about existing code - ie already written ones - that may break because of a change here. How can this change break existing code? |
Anyone extending this code and wiring it on its own doesn't have to check that what it receives is a symfony container until now since we guarantee it, after this change such code would work by luck if it relies on any method that is not part of the PSR-11 replacement. It would truly break only when decorating the service of this factory, maybe we don't care. |
@chalasr as discussed with @nicolas-grekas, there is no bc break as it won't break existing code: the only time the container will no longer be an instance of the symfony container when upgrading will be when using the |
Pleased to see one more container injection removed then. |
|
||
$this->validators[$name] = new $name(); | ||
$this->validators[$name] = new $name(); | ||
} | ||
} elseif (is_string($this->validators[$name])) { |
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.
should has()
be called here too?
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? In case what is returned by the container is a string ?
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.
get()
is called if this check succeeds. We're checking has()
before get()
in the first check above so I'm wondering if we need it here
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.
Above it's needed because we want to know when to fallback to manual instantiating, here it just depends of the exception we want, with a has
the code will fail a few lines later with an InvalidArgumentException, otherwise it will fail in the container.
This should not happen unless the user entered a wrong service, imo it's not worth supporting it.
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.
👍
The Validator's CHANGELOG should mention the deprecation |
Changelog updated ☺ |
UPGRADE-3.3.md
Outdated
@@ -71,6 +71,9 @@ FrameworkBundle | |||
deprecated and will be removed in 4.0. Use the `Symfony\Component\Form\DependencyInjection\FormPass` | |||
class instead. | |||
|
|||
* Extending `ConstraintValidatorFactory` is deprecated and won't be supported | |||
in 4.0. |
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.
could be on one line
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.
updated
throw new InvalidArgumentException(sprintf('The service "%s" must be public as it can be lazy-loaded.', $id)); | ||
} | ||
|
||
if ($definition->isAbstract()) { |
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.
Abstract services should be ignored ie you should "continue". Note that this applies to many other cases in the code base: many passes throw on abstract services, but now that tags can be inherited in child definitions, we should just "continue" instead. Deserves another PR if you'd like to do it :)
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.
Seems like ContainerBuilder::findTaggedServiceIds()
deserves a new argument ;)
I can't do it this week so I opened #21761 in case someone is interested.
…ument type (chalasr) This PR was merged into the 3.3-dev branch. Discussion ---------- [DI] Remove experimental status from service-locator argument type | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #21625 (comment), #21625 (comment), #21710 | License | MIT The `service-locator` argument type is not controversial to me. We know its scope, nothing really surprising, just a map of services to be lazily loaded like `iterator` is (which is not experimental) but keyed. About its api, it's just PSR-11 restricted to objects, nothing that can't be changed safely in the future. As stated in #21625 (comment), it proven its usefulness already. I think what we were looking for by flagging it experimental is just to see it in action, we've 3 opened PRs for that (#21625, #21690, #21730). This allows introducing deprecations for making use of the feature in the core, thus unlocks #21625 and #21690. Commits ------- 46dc47a [DI] Remove experimental status from service-locator argument type
rebase needed |
@nicolas-grekas done. Also, abstract definitions are now ignored and I improved the test readability by removing mocks. |
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.
👍
Thank you @GuilhemN. |
)); | ||
$container = new ContainerBuilder(); | ||
$validatorFactory = $container->register('validator.validator_factory') | ||
->setArguments(array(new ServiceLocatorArgument())); |
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.
broken here, the constructor expects an argument. See #21821
Use a service locator to load constraint validators: it allows them to be private.