Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[DI] Remove experimental status from service-locator argument type#21766

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

Merged

Conversation

@chalasr
Copy link
Member

@chalasrchalasr commentedFeb 26, 2017
edited
Loading

QA
Branch?master
Bug fix?no
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#21625 (comment),#21625 (comment),#21710
LicenseMIT

Theservice-locator argument type is not controversial to me. We know its scope, nothing really surprising, just a map of services to be lazily loaded likeiterator 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.

ro0NL, ogizanagi, and Koc reacted with thumbs up emojisstok reacted with hooray emoji
@chalasrchalasrforce-pushed theservicelocator-nomore-experimental branch fromdad7618 to46dc47aCompareFebruary 26, 2017 10:26
Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍

Copy link
Member

@dunglasdunglas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍

Copy link
Member

@xabbuhxabbuh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👍

@fabpot
Copy link
Member

Thank you@chalasr.

@fabpotfabpot merged commit46dc47a intosymfony:masterFeb 26, 2017
fabpot added a commit that referenced this pull requestFeb 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       | 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
@chalasrchalasr deleted the servicelocator-nomore-experimental branchFebruary 27, 2017 12:07
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@dunglasdunglasdunglas approved these changes

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

@xabbuhxabbuhxabbuh approved these changes

+1 more reviewer

@ogizanagiogizanagiogizanagi approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

3.3

Development

Successfully merging this pull request may close these issues.

7 participants

@chalasr@fabpot@dunglas@nicolas-grekas@xabbuh@ogizanagi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp