onFooInBarAfter initialization it was properly registered in the event map, but at some point the event map entry just vanished.
<on: foo in: bar>
There also was another on: handler which did some stuff whenever bar changed. To "call" that stuff, we just signaled a barChanged event somewhere else:
self signal: #barChanged.It turned out this innocuously looking line was responsible for the trashed on:in: handler! What happened?
Well, an on:in: handler must always be registered to the object that currently is occupying the bar field. But what if bar changes? Then we must unregister the foo handler in the old bar, and re-register it with the new bar. That's why the system installs a barChanged handler behind the scenes, which normally receives the new and old values of bar as arguments.
Now, can you see what happened? If we just signal #barChanged, then the arguments are nil! The current handler will be unregistered, but no new handler gets registered instead!
Do not signal a change event by hand!Of course, we could have constructed a proper change signal like this:
self signalChanged: #barChanged from: bar to: barbut why bother? It's much cleaner to not misuse the system-defined change event. I ended up defining another event, #barModified with a proper handler, which is signaled from both the #barChanged handler and other places.