Skip to content
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

Closed

Conversation

omsmith
Copy link
Contributor

@omsmith omsmith commented May 19, 2016

Checklist
  • tests and code linting passes
  • a test and/or benchmark is included
  • documentation is changed or added
  • the commit message follows commit guidelines
Affected core subsystem(s)

events

Description of change

Fixes: #6873

@nodejs-github-bot nodejs-github-bot added the events Issues and PRs related to the events subsystem / EventEmitter. label May 19, 2016
@@ -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];
Copy link
Contributor

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?

Copy link
Contributor Author

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

@cjihrig
Copy link
Contributor

cjihrig commented May 19, 2016

LGTM with a couple comments.

@omsmith omsmith force-pushed the events-listeners-fix-once-unwrapping branch from 49951dc to 3b2551a Compare May 19, 2016 16:48
@@ -475,3 +475,11 @@ function arrayClone(arr, i) {
copy[i] = arr[i];
return copy;
}

function unwrapListeners(arr) {
var ret = new Array(arr.length);
Copy link
Member

@addaleax addaleax May 19, 2016

Choose a reason for hiding this comment

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

nit: const?

@addaleax
Copy link
Member

LGTM with a nit… #5564 was labelled as semver-major. What do you think?

@cjihrig
Copy link
Contributor

cjihrig commented May 19, 2016

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

@jasnell
Copy link
Member

jasnell commented May 19, 2016

I call bug.

@jasnell
Copy link
Member

jasnell commented May 19, 2016

LGTM if CI is green and @addaleax' nit is addressed.

@omsmith omsmith force-pushed the events-listeners-fix-once-unwrapping branch from 3b2551a to d667704 Compare May 19, 2016 17:49
@omsmith
Copy link
Contributor Author

omsmith commented May 19, 2016

Updated with const

@addaleax
Copy link
Member

CI: https://ci.nodejs.org/job/node-test-commit/3436/

Going to land this if it’s green.

@Fishrock123
Copy link
Contributor

Fishrock123 commented May 22, 2016

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/

@jasnell
Copy link
Member

jasnell commented May 22, 2016

@addaleax
Copy link
Member

Nothing that looks related… @Fishrock123 is it okay for you to consider this a semver-patch one?

@Fishrock123
Copy link
Contributor

I don't have a firm opinion. If you are confident about it, go ahead. :)

@addaleax
Copy link
Member

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 listeners() using .addListener() would restore the previous situation.

So, eh, thanks for making me think twice…

@addaleax
Copy link
Member

i.e. there’s a valid use case for the old behaviour, namely temporarily disabling listeners by storing the result of listeners(), removing all of them and re-attaching them later.

@ChALkeR
Copy link
Member

ChALkeR commented May 23, 2016

This was discussed before in #914, will break several modules, and is clearly a semver-major.
Also related: #5127.

See https://github.com/timoxley/overshadow-listeners/blob/master/index.js, for example.

@ChALkeR ChALkeR added the semver-major PRs that contain breaking changes and should be released in the next major version. label May 23, 2016
@addaleax
Copy link
Member

Could we add an option to .listeners() that defaults to the current behaviour of returning unwrapped listeners to un-semver-major this? Changing the that default could still be discussed as a separate semver-major change…

@jasnell
Copy link
Member

jasnell commented May 23, 2016

I view this one as a bug fix and would rather the default behavior be to
return the unwrapped listeners. Mark it semver-major if necessary but the
current behavior is broken.
On May 23, 2016 3:30 AM, "Anna Henningsen" notifications@github.com wrote:

Could we add an option to .listeners() that defaults to the current
behaviour of returning unwrapped listeners to un-semver-major this?
Changing the that default could still be discussed as a separate
semver-major change…


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#6881 (comment)

@ChALkeR
Copy link
Member

ChALkeR commented May 23, 2016

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

@addaleax
Copy link
Member

Concrete proposal for implementation as an optional feature: addaleax/node@cd0a542310be. What do you think?

@Fishrock123
Copy link
Contributor

Could someone clarify for myself and anyone else who may drop in here what we mean by "unwrapping"? Thanks!

@addaleax
Copy link
Member

@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, .once() uses .on() internally, but wraps the user-supplied function using a closure that, when invoked, first removes itself from the event listener list and then calls the original user-supplied function. This closure has a .listener property that refers to that original function.

Unwrapping refers to returning the .listener property of an event handler, if present, when e.g. emitter.listeners() is called; it makes sense to do that from one perspective, because those are the values that the user actually supplied to .on()/.once(), and they can’t really use the wrapped listeners themselves.

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 listener function in emitter.listeners('foo')[0].

@Fishrock123
Copy link
Contributor

Basically, .once() uses .on() internally, but wraps the user-supplied function using a closure that, when invoked, first removes itself from the event listener list and then calls the original user-supplied function.

Ah right, I totally knew that but didn't link the two... >_<

@jasnell
Copy link
Member

jasnell commented Aug 5, 2016

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

@jasnell
Copy link
Member

jasnell commented Aug 5, 2016

LGTM if CI is green.
CI: https://ci.nodejs.org/job/node-test-pull-request/3547/

@mscdex
Copy link
Contributor

mscdex commented Aug 5, 2016

else
ret = arrayClone(evlistener, evlistener.length);
Copy link
Contributor

@yorkie yorkie Aug 6, 2016

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()?

Copy link
Contributor Author

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.

Copy link
Contributor

@yorkie yorkie Aug 6, 2016

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.

Copy link
Contributor Author

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.

@jasnell
Copy link
Member

jasnell commented Aug 9, 2016

CI is green and CITGM is only showing known flaky failures. Will get this landed.
If there's anything additional that needs to be done here, we can do a follow on PR

jasnell pushed a commit that referenced this pull request Aug 9, 2016
Fixes: #6873
PR-URL: #6881
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
@jasnell
Copy link
Member

jasnell commented Aug 9, 2016

Landed in b7a8a69! (finally ;-) ...)

@jasnell jasnell closed this Aug 9, 2016
@gibfahn gibfahn mentioned this pull request Jun 15, 2017
3 tasks
goto-bus-stop added a commit to goto-bus-stop/node-libs-browser that referenced this pull request Feb 15, 2018
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
events Issues and PRs related to the events subsystem / EventEmitter. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants