[EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgument #23008
Conversation
ded0bb4 to
b2a71e2
Compare
|
now with simplified logic |
|
This patch seems to fix my Issue in #22970. 👍 |
b2a71e2 to
96b7bf0
Compare
| if ($listeners) { | ||
| $this->listeners[$eventName][$priority] = $listeners; | ||
| } else { | ||
| unset($this->listeners[$eventName][$priority]); |
There was a problem hiding this comment.
this "unset" allows better cleanup of the $this->listeners property and explains the replacement of "isset" by "empty" in a few places above
There was a problem hiding this comment.
oh, and this most importantly helps the new implem of hasListeners (which is lazy-compliant now)
|
This also appears to fix #23011 |
| } else { | ||
| $listeners[$k] = $v; | ||
| } | ||
| } |
There was a problem hiding this comment.
Is this identical to the code down in sortListeners()? If so, perhaps a private function resolveListeners($eventName) or something similar? I'm finding some of the logic a bit hard to follow - organizing into a private function(s) might also help me understand things :)
There was a problem hiding this comment.
not sure about the private: performance is critical in this components
not without conflicts, which means process overhead, I'd prefer not |
|
👍 |
|
Some tests would be good for it I think 😄 👍 Edit: ah did not see your comment 😉
|
| if ($v === $listener) { | ||
| unset($listeners[$k], $this->sorted[$eventName]); | ||
| } else { | ||
| $listeners[$k] = $v; |
There was a problem hiding this comment.
can we not use foreach ($listeners as $k => &$v) { instead?
There was a problem hiding this comment.
references don't play well with php 5, I try to avoid them as much as possible
96b7bf0 to
dd68442
Compare
|
Now with tests |
…osureProxyArgument
dd68442 to
c17a009
Compare
|
Thank you @nicolas-grekas. |
…lying on ClosureProxyArgument (nicolas-grekas) This PR was merged into the 3.3 branch. Discussion ---------- [EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgument | Q | A | ------------- | --- | Branch? | 3.3 | Bug fix? | yes | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #22970 | License | MIT | Doc PR | - If we decide to go this way, we might drop ClosureProxyArgument entirely because we won't need it internally. I'll propose it in another PR for discussion if this one is accepted. This PR allows "high-order" listeners, as `array(Closure, method)`. Closure is called to get the actual instance when needed only. How does it look to you? (I'll add tests once confirmed) Commits ------- c17a009 [EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgument
This PR was merged into the 3.3 branch. Discussion ---------- [Di] Remove closure-proxy arguments | Q | A | ------------- | --- | Branch? | 3.3 | Bug fix? | no | New feature? | no | BC breaks? | yes | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - With #23008, we don't need this in core anymore. Let's drop it now. Technically that's a BC break, but for a feature that is very new, and still quite hidden. Doing this now would save us from maintaining this code, and help reduce the overall complexity. Basically reverts #20953 Commits ------- 57daadb [Di] Remove closure-proxy arguments
|
@nicolas-grekas , am I right that now if I create a subscriber like this: <?php
namespace AppBundle\EventListener;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
class TestListener implements EventSubscriberInterface
{
public function __construct()
{
dump('constructor');
}
public static function getSubscribedEvents()
{
return [
'test' => 'test',
];
}
public function test()
{
dump('fired');
}
}I should not see |
|
@vudaltsov not exactly. The profiler itself triggers initialization currently, due to collecting not-called listeners, which gets all of them. |
|
@stof , thank you! Now I understand what the problem was... With profiler disabled everything works as expected, so I can rely on this in production. |
If we decide to go this way, we might drop ClosureProxyArgument entirely because we won't need it internally. I'll propose it in another PR for discussion if this one is accepted.
This PR allows "high-order" listeners, as
array(Closure, method). Closure is called to get the actual instance when needed only.How does it look to you? (I'll add tests once confirmed)