Skip to content

[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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

chalasr
Copy link
Member

@chalasr chalasr commented Feb 22, 2017

Q A
Branch? 3.4
Bug fix? no
New feature? no
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets n/a
License MIT
Doc PR n/a

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).

@chalasr chalasr changed the title Remove container injections deprecations [3.4] Deprecations regarding use of service locators/getter injection Feb 22, 2017
@ogizanagi
Copy link
Contributor

Targets 3.4 (or more if the experimental period for service locators/getter injection is prolonged).

I doubt it will be more anyway, as 3.4 is the last release for Symfony 3.
Can experimental features stay experimental in a new major release?

@chalasr chalasr force-pushed the remove-container-injections-deprecations branch from d10bb99 to d8f02e4 Compare February 22, 2017 17:45
@chalasr
Copy link
Member Author

chalasr commented Feb 22, 2017

@ogizanagi Given "experimental" doesn't fit with semver and considering the following statement:

The core team can decide to extend the experimental period for another minor version on a case by case basis.

I would say yes.

chalasr and others added 2 commits February 22, 2017 18:56
[TwigBundle] Replace container by service locator in ContainerAwareRuntimeLoader

[HttpKernel] Replace container by service locator in LazyLoadingFragmentHandler

Keep legacy feature working
@chalasr chalasr force-pushed the remove-container-injections-deprecations branch from d8f02e4 to 34eeffb Compare February 22, 2017 17:56
@nicolas-grekas
Copy link
Member

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
Copy link
Member

nicolas-grekas commented Feb 25, 2017

ping @fabpot (another option being to remove the experimental flag to feats that have already proven their usefulness in 3.3)

@nicolas-grekas nicolas-grekas added this to the 3.x milestone Feb 25, 2017
@chalasr chalasr closed this Feb 25, 2017
@chalasr chalasr deleted the remove-container-injections-deprecations branch February 26, 2017 11:35
fabpot added a commit that referenced this pull request Feb 26, 2017
…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
@nicolas-grekas nicolas-grekas modified the milestones: 3.x, 3.3 Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants