Skip to content
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

[OptionsResolver] fix adding $triggerDeprecation to Options::offsetGet() #31950

Merged
merged 1 commit into from Jun 9, 2019

Conversation

Projects
None yet
4 participants
@nicolas-grekas
Copy link
Member

commented Jun 8, 2019

Q A
Branch? 4.2
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

This has been added by @yceruto in #28878 but it doesn't make sense to me: the interface has no concept if deprecation (OptionsResolver has!)

@ro0NL

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2019

the idea was for e.g. vendors using OptionsResolver to opt-out from end-user deprecations themselves, i.e. the same reason why SF needs it.

So it's a feature .. kinda :)

@nicolas-grekas

This comment has been minimized.

Copy link
Member Author

commented Jun 8, 2019

Does this have to be at the Options level? Because sure, it also exists on OptionsResolver and it makes sense there.

@ro0NL

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2019

Does this have to be at the Options level?

I think yes, because that's what you typehint for:

$resolver->setDefaults([
    'a' => function (Options $options) {
        $b = $options->offsetGet('b', false); // never triggers
        $c = $options['c']; // always triggers
    },
]);
@yceruto

yceruto approved these changes Jun 8, 2019

Copy link
Contributor

left a comment

Yes, the new argument is an implementation detail of the OptionsResolver. I agree it shouldn't be part of the interface.

@yceruto

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2019

This was about documentation only :) (for IDEs mainly)

@yceruto

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2019

should be target 4.2

@nicolas-grekas nicolas-grekas modified the milestones: 4.3, 4.2 Jun 9, 2019

@nicolas-grekas nicolas-grekas changed the base branch from 4.3 to 4.2 Jun 9, 2019

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:opt-no-deprec branch from 9a422cd to adc7e6a Jun 9, 2019

@nicolas-grekas nicolas-grekas merged commit adc7e6a into symfony:4.2 Jun 9, 2019

1 of 3 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
fabbot.io Your code looks good.
Details

nicolas-grekas added a commit that referenced this pull request Jun 9, 2019

minor #31950 [OptionsResolver] fix adding $triggerDeprecation to Opti…
…ons::offsetGet() (nicolas-grekas)

This PR was submitted for the 4.3 branch but it was merged into the 4.2 branch instead (closes #31950).

Discussion
----------

[OptionsResolver] fix adding $triggerDeprecation to Options::offsetGet()

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

This has been added by @yceruto in #28878 but it doesn't make sense to me: the interface has no concept if deprecation (`OptionsResolver` has!)

Commits
-------

adc7e6a [OptionsResolver] fix adding $triggerDeprecation to Options::offsetGet()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.