Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[DependencyInjection] ServiceSubscriberTrait does not allow non-service "getter" methods #42217

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
kbond opened this issue Jul 21, 2021 · 1 comment · Fixed by #42238
Closed

Comments

@kbond
Copy link
Member

kbond commented Jul 21, 2021

Symfony version(s) affected: 4.2+

Description
When using the ServiceSubscriberTrait, you cannot have methods with no arguments and a class return type that cannot be created as a service. Memoization of a value object/model is a common use-case that would create this problem.

This issue was brought to my attention by @weaverryan who had this issue in a real app.

How to reproduce
https://github.com/kbond/subscriber-trait-bug-reproducer is a reproducer. Clone and run composer install && bin/console lint:container to see the exception. This is the method that causes the problem.

Possible Solution
My initial proposal for this feature required users tag methods they want as services with a @service docblock tag. This was ultimately rejected but perhaps we could bring this idea back with attributes?

#[SubscribedService]
private function service1(): Service1
{
    return $this->container->get(__METHOD__);
}

#[SubscribedService('custom_name')]
private function service2(): Service2
{
    return $this->container->get('custom_name');
}

I'd suggest deprecating the current usage (no attribute) in 5.4 and requiring attributes in 6.0. I don't know how/if this would work with Symfony's BC policy seeing as attributes are PHP8+ and Symfony 5 requires 7.2...

Any other ideas?

@stof
Copy link
Member

stof commented Jul 21, 2021

I don't know how/if this would work with Symfony's BC policy seeing as attributes are PHP8+ and Symfony 5 requires 7.2...

We could trigger the deprecation when running on PHP 8+ (projects have to migrate to PHP 8 before migrating to Symfony 6 anyway as Symfony 6 cannot run on PHP 7.x)

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