-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
events: unwrap #once listeners in #listeners #6881
events: unwrap #once listeners in #listeners #6881
Conversation
@@ -425,9 +425,9 @@ EventEmitter.prototype.listeners = function listeners(type) { | |||
if (!evlistener) | |||
ret = []; | |||
else if (typeof evlistener === 'function') | |||
ret = [evlistener]; | |||
ret = [evlistener.listener ? evlistener.listener : evlistener]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you just do evlistener.listener || evlistener
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing, pushing that up. This was just mirroring the check as written for 'newListener
'.
LGTM with a couple comments. |
49951dc
to
3b2551a
Compare
@@ -475,3 +475,11 @@ function arrayClone(arr, i) { | |||
copy[i] = arr[i]; | |||
return copy; | |||
} | |||
|
|||
function unwrapListeners(arr) { | |||
var ret = new Array(arr.length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: const
?
LGTM with a nit… #5564 was labelled as semver-major. What do you think? |
#6394 got through as a patch, so it could probably go either way. It just depends if we want to look at this as a bug or not. |
I call bug. |
LGTM if CI is green and @addaleax' nit is addressed. |
3b2551a
to
d667704
Compare
Updated with |
CI: https://ci.nodejs.org/job/node-test-commit/3436/ Going to land this if it’s green. |
Should we run citgm against this? I don't understand whether or not there is risk here. Edit: here's a run regardless: https://ci.nodejs.org/view/Node.js-citgm/job/thealphanerd-smoker/277/ |
Couple of citgm failures on ubuntu ppc -> https://ci.nodejs.org/view/Node.js-citgm/job/thealphanerd-smoker/277/nodes=ppcle-ubuntu1404/tapTestReport/ |
Nothing that looks related… @Fishrock123 is it okay for you to consider this a semver-patch one? |
I don't have a firm opinion. If you are confident about it, go ahead. :) |
The more I think about this the more I start to get cautious… e.g. I didn’t realize this so far, but I’d be creating a bug myself in #6635 if this one landed, too, because I was assuming that re-adding the elements from So, eh, thanks for making me think twice… |
i.e. there’s a valid use case for the old behaviour, namely temporarily disabling listeners by storing the result of |
This was discussed before in #914, will break several modules, and is clearly a semver-major. See https://github.com/timoxley/overshadow-listeners/blob/master/index.js, for example. |
Could we add an option to |
I view this one as a bug fix and would rather the default behavior be to
|
@jasnell It looks like there will be no way to re-attach the events then, which could be useful for cloning, intercepting, or temporary disabling events. Perhaps some API should be added that allows that? Edit: obviously missed «no» here, updated. |
Concrete proposal for implementation as an optional feature: addaleax/node@cd0a542310be. What do you think? |
Could someone clarify for myself and anyone else who may drop in here what we mean by "unwrapping"? Thanks! |
@Fishrock123 oh, sorry, wasn’t aware that this isn’t clear here (and that also means that we probably need a better name). So, I hope the following sums up everything so far: Basically, Unwrapping refers to returning the For example, in const emitter = new EventEmitter();
function listener() {}
emitter.once('foo', listener);
emitter.listeners('foo')[0] === listener // this should be true? no?
emitter.listeners('foo')[0].listener === listener // this is currently true, but not documented in any way it would probably reflect user expectations to return the original |
Ah right, I totally knew that but didn't link the two... >_< |
@nodejs/ctc ... looks like this one fell by the way side accidentally. Please take a moment to review (again if you already reviewed it once). |
LGTM if CI is green. |
else | ||
ret = arrayClone(evlistener, evlistener.length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove the arrayClone
function and do replace all arrayClone()
to unwrapListeners()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the other usages of arrayClone
expect the wrapped listeners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However I think the only difference between is that arrayClone
supports a copy with a specified length, 2nd argument and the assignment from .listener
of elements.
The function upwrapListeners
seems to be only used inside to EE.prototype.listeners
, so could we declare this function inside the prototype method to be unwrap
? Both the functions defined at bottom looks like those pure collection ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect declaring unwrapListeners
within listeners
(I believe that's what you're suggesting?) to result in a performance degradation.
CI is green and CITGM is only showing known flaky failures. Will get this landed. |
Landed in b7a8a69! (finally ;-) ...) |
Matches the Node 8 API. v1 matched Node 4, and some new methods have since been introduced (notably `prepend[Once]Listener`). The major bump in `events` was because: - There is a breaking change in the `listeners()` method regarding `once()` listeners nodejs/node#6881 I think it's super unlikely to affect anyone, but there you go. - The gzipped size almost doubled from 1.1KB to 2.1KB. It'll shrink a bit because some patches have since landed in Node that remove some code, but it'll still be bigger than it was because of the new methods. Deets: https://github.com/Gozala/events/releases/tag/v2.0.0
Checklist
Affected core subsystem(s)
events
Description of change
Fixes: #6873