Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[3.4] Deprecations regarding use of service locators/getter injection#21710
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
[3.4] Deprecations regarding use of service locators/getter injection#21710
Uh oh!
There was an error while loading.Please reload this page.
Conversation
ogizanagi commentedFeb 22, 2017
I doubt it will be more anyway, as 3.4 is the last release for Symfony 3. |
d10bb99 tod8f02e4Comparechalasr commentedFeb 22, 2017
@ogizanagi Given "experimental" doesn't fit with semver and considering the following statement:
I would say yes. |
[TwigBundle] Replace container by service locator in ContainerAwareRuntimeLoader[HttpKernel] Replace container by service locator in LazyLoadingFragmentHandlerKeep legacy feature working
d8f02e4 to34eeffbComparenicolas-grekas commentedFeb 25, 2017
This is going to be a nightmare to track to me... Except for the UPGRADE notes, I'd prefer to have the code side be implemented right into the PR introducing the new proposed way of things so that the test suite can spot any missing upgrade of the code base. |
nicolas-grekas commentedFeb 25, 2017 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
ping@fabpot (another option being to remove the experimental flag to feats that have already proven their usefulness in 3.3) |
…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 | MITThe `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
Uh oh!
There was an error while loading.Please reload this page.
In order to don't do it twice, this includes the deprecations for#21625.
Targets 3.4 (or more if the experimental period for service locators/getter injection is prolonged).