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: _events should be an own property #2046

Closed

Conversation

vkurchatkin
Copy link
Contributor

2c6b424 fixed this problem for the case where
EventEmitter constructor is invoked. If is not, shared
_events were still used. This commit ensures that listeners
are added only to own _events.

See: nodejs/node-v0.x-archive#7405
@mscdex mscdex added the events Issues and PRs related to the events subsystem / EventEmitter. label Jun 23, 2015
@@ -20,6 +20,17 @@ EventEmitter.prototype._maxListeners = undefined;
// added to it. This is a useful default which helps finding memory leaks.
EventEmitter.defaultMaxListeners = 10;

function ensureEvents(emitter) {
Copy link
Member

Choose a reason for hiding this comment

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

ensureXxx function should not have a side-effect (no modified state).
I feel initializeXxx is better or remove side-effects like:

function ensureEvents(emitter) {
  if (!emitter._events ||
      emitter._events === Object.getPrototypeOf(emitter)._events) {
    return false;
  }
  return true;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Disagree. ensure implies idempotency, nothing more

@bnoordhuis
Copy link
Member

LGTM but maybe you can add a regression test for the two-level inheritance I described here?

@brendanashworth
Copy link
Contributor

Not sure about this. If it is incorrect, why should we support it? It isn't supported in any other inheritable node class and just leads to lots of annoying legacy code.

@jasnell
Copy link
Member

jasnell commented Nov 16, 2015

@vkurchatkin ... is this still something you'd like to pursue?

@jasnell jasnell added the stalled Issues and PRs that are stalled. label Nov 16, 2015
@vkurchatkin
Copy link
Contributor Author

@jasnell actually, no, I don't think it's a good idea anymore

@jasnell
Copy link
Member

jasnell commented Nov 16, 2015

Thanks @vkurchatkin !

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. stalled Issues and PRs that are stalled.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants