Rebinding a KeyHandler should create a new instance instead of replacing the callback

[kasper]

Rebinding a KeyHandler should create a new instance instead of replacing the callback to ensure a clean state for the new handler.

• Version: 2.1.1

[kasper]

@mafredri @ontucker @jasonm23 I think I’ll fix this in the next minor version as this is more of a design flaw than a bug. As this will make some breaking changes to the API, I wanted to get your opinions. How about this:

1. Key handlers will always be enabled by default.
2. All key handlers will have unique hashes even if they consist of the same key combinations. This is the same behaviour as with event and timer handlers.
3. Subsequently, you can then have multiple key handlers for a key combination, but only one will be enabled at a time.
4. If a key is bound with a previously existing key combination, the latest active handler will be disabled, but the user is still responsible for releasing the reference.
5. Key handlers can be enabled and disabled as desired, but only one can be active for a key combination at a time.

Would this make sense?

[mafredri]

What you described is pretty much what I'd expect the behavior to be, makes perfect sense to me 👍.

[ontucker]

Me too. One point in (4) is that it shouldn't be an error to disable a handler which has, unbeknownst to you, been disabled by another handler with the same key combination being enabled overtop of it.

One thing unspecified here is whether the key handlers for a given key combination are effectively like a stack where last-enabled wins, but if you disable that, the previously-enabled one gets re-enabled again. That could simplify things for modules which want to temporarily override key combinations and then put things back the way they were without the owners of those combos having to do anything.

Note that it might also make sense to have a keyhandler emit an event when it becomes disabled due to another one stomping on it, so the owner knows that the handler is inactive.

[kasper]

@ontucker Good points! It’s currently OK to disable a key handler that has been already disabled. Nothing will happen, but the API will return true. This shouldn’t change. Emitting events about the state changes is definitely a good idea if a new handler disables a previous one.

The problem with implementing a stack-like behaviour is that Phoenix currently has no idea when the user releases the references. This all happens inside the JavaScript’s scope. So most likely this behaviour should be the user’s responsibility,

This leads to another idea, should new key handlers that have the same key combinations as active handlers in fact be disabled after creation? Would this be more intuitive? This way nothing unexpected would happen.

[ontucker]

I have to admit, I find the "key handler is disabled when the user releases the reference" behavior a bit odd and un-javascript-ish. In most javascript event APIs, the handler stays attached whether you retain a reference to it or not. If you had this model, Phoenix wouldn't need to care whether the user had released references -- the handler would stay active until it's explicitly removed or superceded. I acknowledge you may have internal architectural reasons this model is more desirable, though.

[kasper]

@ontucker This is defined by two reasons: 1.) how memory management is handled in JavaScriptCore — this states that Objective-C cannot retain JavaScript callbacks, otherwise we will end in a retain cycle (ARC vs. garbage collection). It also requires that the JavaScript context keeps a reference to the object. When this reference is released JavaScriptCore knows it can finally garbage collect the object. This abstraction also means, the general runtime knows very little when objects are actually released. 2.) An architectural desicision that keeps Phoenix extremely lightweight.

Obviously, this all is completely internal behaviour partly demanded by memory management. We could implement a wrapper within the JavaScript context to take care of keeping the references alive and abstract this from the user. You could in fact do this yourself. This is what other JavaScript libraries (or rather browsers/runtimes) do.

Obviously this is quite language technical, but someone always needs to take care of the object lifecycle.

In fact, currently Phoenix doesn’t know or care when the user releases the handlers and the behaviour you described would need the complete opposite if it were to be implemented in Objective-C runtime. :)