Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgument#23008

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
fabpot merged 1 commit intosymfony:3.3fromnicolas-grekas:subscriber-registry
Jun 1, 2017

Conversation

@nicolas-grekas
Copy link
Member

@nicolas-grekasnicolas-grekas commentedJun 1, 2017
edited
Loading

QA
Branch?3.3
Bug fix?yes
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#22970
LicenseMIT
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, asarray(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)

chalasr, weaverryan, and dmaicher reacted with thumbs up emoji
Copy link
Member

@chalasrchalasr left a comment
edited
Loading

Choose a reason for hiding this comment

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

I think its a nice have for the dispatcher itself and that the bit of complexity added here isn't a big deal as it allows removing much more from DI. 👍
(adding some tests for this would be nice I guess)

@nicolas-grekasnicolas-grekasforce-pushed thesubscriber-registry branch 2 times, most recently fromded0bb4 tob2a71e2CompareJune 1, 2017 11:23
@nicolas-grekas
Copy link
MemberAuthor

now with simplified logic

@Gemineye
Copy link

This patch seems to fix my Issue in#22970. 👍

if ($listeners) {
$this->listeners[$eventName][$priority] =$listeners;
}else {
unset($this->listeners[$eventName][$priority]);
Copy link
MemberAuthor

@nicolas-grekasnicolas-grekasJun 1, 2017
edited
Loading

Choose a reason for hiding this comment

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

this "unset" allows better cleanup of the$this->listeners property and explains the replacement of "isset" by "empty" in a few places above

Gemineye reacted with thumbs up emojiGemineye reacted with hooray emoji
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

oh, and this most importantly helps the new implem of hasListeners (which is lazy-compliant now)

@weaverryan
Copy link
Member

This also appears to fix#23011

Copy link
Member

@weaverryanweaverryan left a comment

Choose a reason for hiding this comment

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

Theisset ->empty change added some complexity, at least for reviewing (could that be done in a separate PR?). But, it makes sense to me, looks good and obviously all the existing tests still pass

}else {
$listeners[$k] =$v;
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Is this identical to the code down insortListeners()? If so, perhaps aprivate 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 :)

ostrolucky reacted with thumbs up emoji
Copy link
MemberAuthor

@nicolas-grekasnicolas-grekasJun 1, 2017
edited
Loading

Choose a reason for hiding this comment

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

not sure about the private: performance is critical in this components

@nicolas-grekas
Copy link
MemberAuthor

nicolas-grekas commentedJun 1, 2017
edited
Loading

could that be done in a separate PR?

not without conflicts, which means process overhead, I'd prefer not

@weaverryan
Copy link
Member

👍

@dmaicher
Copy link
Contributor

dmaicher commentedJun 1, 2017
edited
Loading

Some tests would be good for it I think 😄 👍

Edit: ah did not see your comment 😉

(I'll add tests once confirmed)

if ($v ===$listener) {
unset($listeners[$k],$this->sorted[$eventName]);
}else {
$listeners[$k] =$v;
Copy link
Contributor

Choose a reason for hiding this comment

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

can we not useforeach ($listeners as $k => &$v) { instead?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

references don't play well with php 5, I try to avoid them as much as possible

dmaicher reacted with thumbs up emoji
@nicolas-grekasnicolas-grekas changed the title[EventDispatcher] Handle lazyness internally instead of relying on ClosureProxyArgument[EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgumentJun 1, 2017
@nicolas-grekas
Copy link
MemberAuthor

Now with tests

dmaicher and chalasr reacted with thumbs up emoji

@fabpot
Copy link
Member

Thank you@nicolas-grekas.

@fabpotfabpot merged commitc17a009 intosymfony:3.3Jun 1, 2017
fabpot added a commit that referenced this pull requestJun 1, 2017
…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
@nicolas-grekasnicolas-grekas deleted the subscriber-registry branchJune 1, 2017 20:47
nicolas-grekas added a commit that referenced this pull requestJun 2, 2017
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#20953Commits-------57daadb [Di] Remove closure-proxy arguments
@fabpotfabpot mentioned this pull requestJun 5, 2017
@vudaltsov
Copy link
Contributor

@nicolas-grekas , am I right that now if I create a subscriber like this:

<?phpnamespaceAppBundle\EventListener;useSymfony\Component\EventDispatcher\EventSubscriberInterface;class TestListenerimplements EventSubscriberInterface{publicfunction__construct()    {dump('constructor');    }publicstaticfunctiongetSubscribedEvents()    {return ['test' =>'test',        ];    }publicfunctiontest()    {dump('fired');    }}

I should not seeconstructor in the profiler's dump section until thetest event is fired?

@stof
Copy link
Member

stof commentedOct 20, 2017
edited
Loading

@vudaltsov not exactly. The profiler itself triggers initialization currently, due to collecting not-called listeners, which gets all of them.

@vudaltsov
Copy link
Contributor

@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.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@weaverryanweaverryanweaverryan left review comments

@fabpotfabpotfabpot approved these changes

@chalasrchalasrchalasr approved these changes

+2 more reviewers

@dmaicherdmaicherdmaicher left review comments

@ogizanagiogizanagiogizanagi approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

3.3

Development

Successfully merging this pull request may close these issues.

10 participants

@nicolas-grekas@Gemineye@weaverryan@dmaicher@fabpot@vudaltsov@stof@ogizanagi@chalasr@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp