allow modules to react to variable_set() or variable_del()

Who could possibly object to something so simple and yet so awesome :-D
You've set it to D8 though :-(
Just subscribing for now.

So this patch needs at minimum to add hook_variable_get/set() to bootstrap_hooks(). Otherwise, the hook won't properly function until bootstrap_full.

Performance-wise I'm not so excited about adding more bootstrap hooks, or increasing the overhead of variable_get/set() by adding invokes. Invokes when added up in all variable_get() calls could cause a significant regression, even if barely any modules implement the hook.

The idea of giving modules the ability to react to every little thing is certainly inviting to module developers, but I would be cautious that so oft-used functions as these could become heavyweights as a result, i.e. who knows what stupid stuff people are going to do with this hook? :)

oh, I see. no hook introduced for variable_get(). Whoops. Scratch the performance concerns in #2.

Just curious, what's your use case? Trying to place this conceptually in the new D8 butler/context system, which I think would gobble up variable_get/set into something more structured.

Yeah, I can't help feeling that D8 will hopefully move towards a much more standardized way of getting in on the action of inserts and updates, not that I've been following the butler movement... (*makes note to do so*)
So this patch really should be for D7. Go on - I dare you - what's the worst that can happen? ;-)

One use case is #1032700-14: Add caching to hook_admin_paths(). Core has variable_get()s in some implementations of hook_admin_paths(), so if we're going to cache results for that hook, we have to clear the cache when those variables are changed. The current patch in that issue does it in a form submit handler, which is the best we can do in current D7, but obviously won't help if somebody does a drush vset. This hook would solve that problem much more robustly and elegantly.

Added to bootstrap_hooks, and changed the array_key_exists() to an isset: since we set to NULL when key does not exist, the net result is the same, although the test logic is not identical.

Subscribing.
Sorry to clutter the issue thread, but we don't have any other way to be notified of individual thread updates or get them in our personal 'my issues' queue, do we?

Jonathan

Bumping to d8

#1646580: Implement Config Events and Listeners, and storage realms for localized configuration