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

[HttpKernel] Replace ArgumentValueResolverInterface by ValueResolverInterface #47363

Merged
merged 1 commit into from Aug 24, 2022

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Aug 23, 2022

Q A
Branch? 6.2
Bug fix? no
New feature? no
Deprecations? yes
Tickets -
License MIT
Doc PR -

Now that I looked at argument value resolvers more closely, I think that we can improve them a bit.
The issue I spotted is that by having two methods (supports() and resolve()), we 1. require some correlation between both that isn't enforced by any contracts, 2. force some duplicate logic between the two and 3. as a consequence incur a needless perf overhead on the hotpath.

I hereby propose to remove the supports() method and allow resolve() to return the empty array instead, to signal that an argument is not supported by a specific value resolver.

For perf also, I made all resolve() methods return arrays instead of generators, which are overhead in our cases.

The changes to EntityValueResolverTest are a very good example at where the current design is fragile. Nothing prevents us from having de-correlated supports() and resolve() methods right now, and we felt into that trap.

@lyrixx
Copy link
Member

lyrixx commented Aug 23, 2022

I really like this move 👍🏼
It's much simpler

@fabpot
Copy link
Member

fabpot commented Aug 24, 2022

Thank you @nicolas-grekas.

@@ -18,6 +18,8 @@
* Responsible for resolving the value of an argument based on its metadata.
*
* @author Iltar van der Berg <kjarli@gmail.com>
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe a bit late cr seeing the code is already merged but shouldn't we have some sort off:

trigger_deprecation('symfony/http-kernel', '6.2', 'The "%s" interface is deprecated.', ValueResolverInterface::class);

to inform the user on code execution @nicolas-grekas ?

Copy link
Member

Choose a reason for hiding this comment

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

DebugClassLoader will trigger it when you implement it, which is much better than triggering it when it is autoloaded (core classes still need to implement it for BC)

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool is this the case for all interfaces that are deprecated when you are running debug mode?

Copy link
Member

Choose a reason for hiding this comment

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

yes

javiereguiluz added a commit to EasyCorp/EasyAdminBundle that referenced this pull request Nov 25, 2022
…luz)

This PR was squashed before being merged into the 4.x branch.

Discussion
----------

Add compatibility with ValueResolverInterface

This avoids a deprecation when upgrading to Symfony 6.2. See symfony/symfony#47363

Commits
-------

497b39c Add compatibility with ValueResolverInterface
derrabus added a commit to symfony/psr-http-message-bridge that referenced this pull request Jul 25, 2023
This PR was merged into the 2.2-dev branch.

Discussion
----------

Implement ValueResolverInterface

Follows symfony/symfony#47363

Commits
-------

0b54b85 Implement ValueResolverInterface
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.

None yet

7 participants