You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm considering making isListening readonly. Right now, you can set it to false to temporarily remove the listener from its associated event, and set it to true to receive events again. Currently, doing that will make the listener lose its place in the call order (assuming #43 gets fixed).
Instead, there could be a disable method for disabling the listener without losing its place, and an enable method for allowing events to be handled again. Also, a destroy method would be added for removing the listener from its event forever; which would be used for cancelling one-time listeners and automatically clearing out dereferenced listeners.
I'm curious what anyone else thinks of this change. Would the breaking change be worth it? I'm also open to suggestions on the naming of the proposed methods.
The text was updated successfully, but these errors were encountered:
I'm considering making
isListening
readonly. Right now, you can set it tofalse
to temporarily remove the listener from its associated event, and set it totrue
to receive events again. Currently, doing that will make the listener lose its place in the call order (assuming #43 gets fixed).Instead, there could be a
disable
method for disabling the listener without losing its place, and anenable
method for allowing events to be handled again. Also, adestroy
method would be added for removing the listener from its event forever; which would be used for cancelling one-time listeners and automatically clearing out dereferenced listeners.I'm curious what anyone else thinks of this change. Would the breaking change be worth it? I'm also open to suggestions on the naming of the proposed methods.
The text was updated successfully, but these errors were encountered: