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

Symfony 6.2 deprecations still #211

Open
michnovka opened this issue Dec 15, 2022 · 3 comments
Open

Symfony 6.2 deprecations still #211

michnovka opened this issue Dec 15, 2022 · 3 comments

Comments

@michnovka
Copy link
Contributor

The "Elao\Enum\Bridge\Symfony\HttpKernel\Controller\ArgumentResolver\BackedEnumValueResolver" class implements "Symfony\Component\HttpKernel\Controller\ArgumentValueResolverInterface" that is deprecated since Symfony 6.2, implement ValueResolverInterface instead.

I am using 2.1.2

@ogizanagi ogizanagi added the Unconfirmed to inspect / reproduce label Dec 15, 2022
@ogizanagi
Copy link
Member

Probably for the same reason as detected in #205, since since the controller arg resolvers are added to the annotations.map file from the FrameworkExtension.

So we might need a solution like in https://github.com/Elao/PhpEnums/blob/2.x/src/Bridge/Symfony/HttpKernel/Controller/ArgumentResolver/QueryBodyBackedEnumValueResolver.php to support both interfaces depending on the version…

@ogizanagi ogizanagi removed the Unconfirmed to inspect / reproduce label Dec 15, 2022
@michnovka
Copy link
Contributor Author

Ugh... thats so ugly solution with the code repetition. Cant we think of some better approach? Lets see how others handle this

@ogizanagi
Copy link
Member

That's particularly annoying to do this for the BackedEnumValueResolver since it would not even to be used, but to trigger a deprecation for the end user to switch to the Symfony one directly…

Lets see how others handle this

AFAIK, this is the most common, efficient way 😄

Specifically for our case with BackedEnumValueResolver, perhaps a class alias to the Symfony 6.2 resolver would be enough when available, but that would not allow to trigger our own deprecation to ask the developper to switch to the Symfony FQCN.

The thing is, I clearly doubt this was expected in symfony/symfony#23776. The resolvers are only added to this map because they are in a **\Controller\** ns, but there is no benefit to it and it becomes annoying now that the resolver interface changes and triggers a deprecation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants