-
Notifications
You must be signed in to change notification settings - Fork 41
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
EventEmitter spec needs to be defined more clearly #82
Comments
We agreed that:
|
Removing only one seems to work but doesn't. In particular, suppose you do
Then you do
which one gets removed? |
But we don't remove only one, in this PR the |
Yes. I'm saying that the alternative behaviour of removing only one, which node does, is harder to make useful and intuitive. |
Ah, yes, OK, sorry I misunderstood. If you're happy with the PR for ably-js then I will update docs and close this issue |
It's probably worth it to specify what happens when you register a listener more than once. |
Ideally that would be a no-op - ie on the second call the listener doesn't get re-added, and when the event fires it calls the listener only once. To implement this adds to the cost of
So I think the first option is better than the alternatives. |
That's what I implemented at ably/ably-cocoa#179, basically for the first point in your list. (More concretely, the second I was about to scratch that and mimic Node.js' behavior, should I leave it as it is? |
This is correct I think.
I think so, yes. Definitely don't "fix" it before we've finished this discussion. |
I disagree. I think it's quite plausible that the same callback could be registered twice, and I don't see why we would ever want to dedupe that. I don't think any developer would ever expect that a listener registered twice would only ever fire once, that is just confusing and adds unnecessary complexity IMHO. In the case of an |
I would, if I thought that listeners are treated as elements in a set, which is what the The fact that you got confused about |
I don't really see it suggests that. Docs for eventListener for Node.js at least say I appreciate it could be interpreted in different ways, and I think the confusion lies with more Saying all this, I question whether we should deviate from the Node.js implementation if we can't agree. |
Yes, but the point is that it is never addressable as an array; entries in the collection are only ever identifiable by their own identity (ie event and listener) which makes the abstraction more suggestive of a set. |
Sorry, that's not true, https://nodejs.org/api/events.html#events_emitter_listeners_event returns an array of listeners.
Well no, they have an index. In fact, they also are publicly exposed in the ably-js implementation, see https://github.com/ably/ably-js/blob/master/common/lib/util/eventemitter.js#L5-L8, which I personally dislike.
I could see that if the object was intended as a data store of some sort, but if it was, then it would expose suitable methods such as Perhaps we should have a call to discuss tomorrow as we should finalise this either way. |
We agreed on a call to go with the array-like behavior, but having |
Also, remove "ignored" list for total listeners; `off` will just be a no-op if called with a specific event and a total listener. See: ably/docs#82 #179 (comment)
This can be closed now, see 1fb9c7f |
See https://github.com/ably/ably-ios/pull/179/files#r51544655
The text was updated successfully, but these errors were encountered: