Some non-meme thoughts (I'm done with them, Kelly-- thanks for pointing out the misdirections intrinsic to the concept):

The current implementation of gnome-filer is fatally flawed. I'm not doing any real kind of memory management; I was hoping a good method would pop up, and I could have some sort of coherent strategy.

No such luck.

Currently, the watchpoint mechanism uses a gpointer for data storage, and doesn't do any allocation or deallocation. Really, I should use a GTK_ARG datatype for storage; then I can copy strings and handle internal (to the object) memory management, and leave everything else alone. But does that make sense? Or should I leave strings alone, too, and count on the application to handle memory? Or should I strongly-type everything, and only allow lists of GTK_ARGS for compound data types?

Too many questions.

I suspect I should just count on the application to handle memory management. I mean, the language plug-ins can handle memory for user-space programs; and for the gnome-filer designer application, I can probably handle my own memory. If I count on the object plug-ins to handle memory, there will be too many special cases. Hell, everything will be a special case. So perhaps there will be fewer problems if the application itself keeps track of everything.

In any case, the current implementation of gnome-filer is fatally flawed.