An editor unbinds a shortcut by the function value it was registered with - why can an inline literal break that?

## Registration stores a value; removal matches one A registry that supports removal has to answer *which binding do you mean?*. The common contract is: the caller hands back the same function value it registered, and the registry removes the entry holding that value. That contract quietly makes the **identity of a function value** part of the API, which is the part most callers never think about. It matters because a function value is produced by evaluating an expression. An inline literal is an expression. Evaluating it twice generally makes two values, and the two are not related to each other by the fact that their bodies were spelled the same way. Matching is done on the value handed over, not on the text it came from - and no language promises structural comparison of function bodies. ## Why two identical literals are two values ``` bind("ctrl+s", function() save() end) unbind("ctrl+s", function() save() end) // a second value; nothing matches ``` The second line builds a new value and asks the registry to remove a binding holding it. There is no such binding. Languages differ on whether an implementation is ever allowed to reuse a value for a literal that captures nothing from around it, so the safe rule is the strong one: **assume a fresh value per evaluation, and never depend on two evaluations agreeing.** The repaired version refers to one value twice: ``` handler = function() save() end bind("ctrl+s", handler) unbind("ctrl+s", handler) // same value; the entry is found ``` ## What the failure looks like in production The bug is quiet at the moment it happens and loud later: - A view is opened, binds its shortcuts, is closed, and unbinds nothing. - Reopening the view binds a second set. One key press now runs the action twice, then three times, then four. - The registry holds every stale entry alive, and through them whatever the bodies reference - so memory grows with the number of times the screen was visited. - Actions that looked idempotent hide the count; actions that insert text or send a request expose it immediately, usually in a bug report about duplicates. The diagnostic that settles it quickly is to count the registry's entries for one key over a session. A count that climbs with navigation is the signature; no amount of reading the unbind call site will show it, because that call site looks correct. ## Designs that remove the question | approach | how removal identifies the binding | failure mode it leaves | |---|---|---| | Match the function value | caller supplies the same value | a re-evaluated literal silently matches nothing | | Hold the value in a variable | one value, referred to twice | someone later inlines the variable back | | Return a token from bind | an opaque handle the caller keeps | a stale token, which can be reported explicitly | | Key-scoped removal | remove everything under a key | removes another owner's binding too | In order of how much they rely on caller discipline: 1. **Keep the value.** One variable or one named declaration, used at both calls. Cheapest, and adequate when one module owns the binding. 2. **Return a token.** The bind call hands back a handle; unbind accepts only a handle. The caller cannot reproduce a wrong value because it never constructs one, and a handle already removed can be rejected loudly instead of silently missing. 3. **Scope removal to an owner.** Registration records which component bound it, and teardown removes everything that component registered. This survives the case where the component no longer has any of its values in hand. ## When referring to a name is still not enough One refinement worth knowing: referring to the same name usually means referring to the same value, but not always. In some languages, fetching a routine that is attached to an object produces a freshly built value on each access, so two references to what looks like one name yield two values and the removal fails in exactly the same way. The rule that always holds is the one about evaluation, not about spelling: **capture the value once, keep it, and hand back the thing you kept.** ## The general lesson This is the first-class property biting back. Because behaviour is an ordinary value, it has the same questions an ordinary value has - where is it stored, who else holds it, and what does it mean for two of them to be the same. A candidate who can name identity as the mechanism, show the two-evaluation trace, describe the duplicate-handler symptom and propose a token-based contract is demonstrating exactly the production judgment the question is asking for.