Add 'off' method to ListWatch and Informer which allows for the removal of callbacks #323
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #322
Why was a call to slice on each array added before passing to calling functions?
Without it, the second test added, "mutating handlers in a callback should not affect those which remain", will fail. The calling functions use Array.prototype.forEach. From MDN
Will slice be slow?
Slice makes a shallow copy of the array, its linear with the number of callbacks added for a particular verb. Overhead should be minimal. If it is a concern, a more complex solution could be devised where .on and .off do not write to the callbackCaches during a forEach, however I prefered simplicity.
Why was the initialization of the callbackCache verbs moved to the constructor
Without it, more complex semantics are needed to determine if it is safe to call .slice in the various locations (i.e. callbackCache[VERB] may be null and .slice would fail without a check).
I think this centralizes the location of verb checking now that it happens in two locations nicely