Thursday, February 17, 2005

Change events are special

I just spent a few hours chasing a very mysterious bug, where an event handler was properly called the first time, but never again. This was a rather unspecial on:in: handler:
<on: foo in: bar>
After initialization it was properly registered in the event map, but at some point the event map entry just vanished.

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!

Lesson learned:
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: bar
but 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.

No comments: