Skip to content

[DoctrineBridge] Invokable event listeners #32486

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

Merged
merged 1 commit into from
Aug 9, 2019

Conversation

fancyweb
Copy link
Contributor

@fancyweb fancyweb commented Jul 10, 2019

Q A
Branch? 4.4
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR symfony/symfony-docs#11992

Invokable Doctrine entity listeners will likely be supported in the next version of the DoctrineBundle (cf doctrine/DoctrineBundle#989).

I think it would also be great to support it for Doctrine event listeners.

@yceruto yceruto added this to the next milestone Jul 10, 2019
@alcaeus
Copy link
Contributor

alcaeus commented Jul 10, 2019

Invokable entity listeners will definitely be in DoctrineBundle 1.12, so I'm all for merging this PR for consistency 👍

@fancyweb fancyweb force-pushed the invokable-doctrine-event-listeners branch 2 times, most recently from 1d55b2b to 61fab3e Compare July 17, 2019 12:07
@alcaeus
Copy link
Contributor

alcaeus commented Jul 30, 2019

doctrine/DoctrineBundle#989 has been merged - what's the status here?

@fancyweb
Copy link
Contributor Author

I guess a review / approval would help 😄

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Jul 31, 2019

With the bundle supporting this soon, I'm 👎 here: this adds overhead on the critical path of the dispatcher ( a call to SplObjectHash::offsetGet())

@alcaeus
Copy link
Contributor

alcaeus commented Jul 31, 2019

The idea was to support it in both kinds of listeners for consistency. Entity listeners are tracked in DoctrineBundle while this PR covers global Doctrine listeners.

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Jul 31, 2019

I'm talking with @fancyweb on Slack, getting better insight here :)

I don't think this is really a good idea, as using __invoke make things more cryptic. A correctly named method is better. I wouldn't like to open a class and spend more time to discover what it listens too. Yes, local conventions can help but global ones mean broader standardization. Also, having two ways to do something means we're going to have to explain it to ppl. This reasoning applies to doctrine/DoctrineBundle#989 too :)

On the performance side also, please consider my argument: SplObjectHash::offsetGet on the critical path is not free. Using a simple+get_class could remove this objection.

But that's only my first reaction, take it as a maybe hint or ignore it :)
I won't block on this if others think this is still a desired improvement.

@fancyweb fancyweb force-pushed the invokable-doctrine-event-listeners branch from d6fd201 to 58f98ce Compare July 31, 2019 14:59
@fancyweb
Copy link
Contributor Author

I just changed the implementation to not use SplObjectStorage anymore.

get_class cannot be used because the same listener class can technically be used by 2 different events (one with the "__invoke" method and the other with the "eventName" method) (⚠️ but don't do it).

But let's allow __invoke! It will be coherent with the DoctrineBundle + coherent with the Symfony event dispatcher component.

__invoke will only be a fallback, you don't have to use it. We are not trying to force a new way to do things.

I wouldn't like to open a class and spend more time to discover what it listens too.

It depends your code structure. If your listener is in a Doctrine\Listener\LoadClassMetadata you know what you are listening to.

Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

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

Thanks, that removes my technical objection. I feel like my other objections aren't strong enough to refuse this PR, because we did it already elsewhere. So good to go for me, thanks.

@fancyweb fancyweb force-pushed the invokable-doctrine-event-listeners branch 3 times, most recently from 572d007 to 55d0142 Compare July 31, 2019 20:20
@fancyweb
Copy link
Contributor Author

I detected a fail in my implementation and had to rework it. The $methods array have now a depth of 2 to store the methods by event and by hash.

@nicolas-grekas
Copy link
Member

small rebase needed

@fancyweb fancyweb force-pushed the invokable-doctrine-event-listeners branch from 55d0142 to 47e872a Compare August 5, 2019 12:08
@fancyweb
Copy link
Contributor Author

fancyweb commented Aug 5, 2019

@nicolas-grekas

@fabpot
Copy link
Member

fabpot commented Aug 9, 2019

Thank you @fancyweb.

@fabpot fabpot merged commit 47e872a into symfony:4.4 Aug 9, 2019
fabpot added a commit that referenced this pull request Aug 9, 2019
This PR was merged into the 4.4 branch.

Discussion
----------

[DoctrineBridge] Invokable event listeners

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | symfony/symfony-docs#11992

Invokable Doctrine entity listeners will likely be supported in the next version of the DoctrineBundle (cf doctrine/DoctrineBundle#989).

I think it would also be great to support it for Doctrine event listeners.

Commits
-------

47e872a [DoctrineBridge] Allow invokable event listeners
@fancyweb fancyweb deleted the invokable-doctrine-event-listeners branch August 9, 2019 06:43
javiereguiluz added a commit to symfony/symfony-docs that referenced this pull request Sep 2, 2019
This PR was merged into the 4.4 branch.

Discussion
----------

[Doctrine] Invokable event listeners

Doc for symfony/symfony#32486

Commits
-------

736d96c [Doctrine] Invokable event listeners
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.4 Oct 27, 2019
This was referenced Nov 12, 2019
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.

7 participants