>> Can you elaborate on your third point? What would a class need to do to affect debugging info?
Common implementations are a function pointer + void* pair, which in most debuggers just show you two opaque addresses. Better to include a info block -- at least in debug builds -- with polymorphic type pointers that can actually deduce the type and show you all the fields of the receiver.
>> sometimes an architecture can be vastly simplified if the source of information can abstracted away.
"sometimes" is doing a lot of heavy lifting here. That's my whole point -- more often than not I see some type of homespun functor used in cases that are _not_ simplified, but actually complicated by the unnecessary "plumbing."
>> RAII and architecture primarily address this
If the receiver uses RAII to clean up the callback, then you've reintroduced the "type-intrusiveness" that functors are meant to avoid...?
> most debuggers just show you two opaque addresses
This has not been my experience. But I haven't needed to deal with RTTI disabled.
By RAII, I mean using destructors to unregister a callback. This covers 99.9% of use cases. Generally callback registration is not where you really want type erasure anyways.
>> By RAII, I mean using destructors to unregister a callback.
_Whose_ destructor, if not the receiving-type? Is there a third "binding" object, because then you have three potentially-unrelated lifetimes.
>> Generally callback registration is not where you really want type erasure anyways.
I'm responding to the article: "Some mechanisms for doing callbacks require a modification to, or derivation of, the caller or callee types. The fact that an object is connected to another object in a particular application often has nothing to do with its type. As we'll see below, mechanisms that are type intrusive can reduce the flexibility and increase the complexity of application code. "
> Whose_ destructor, if not the receiving-type
The receiving type should control the lifetime of any callbacks to itself that it gives away. The destructor is the best place to ensure this gets properly cleaned up.
Like anything, custom callbacks can be used well or misused. Design is a matter of expertise and taste bordering on an art form. Connecting framework implementation and business logic can be done cleanly or clumsily. I am skeptical of an argument that callbacks have a code smell prima facie.
I don't disagree, but the article does. RH describes an architecture where setup functions create callbacks, independent of the receiving type. If I were to steelman him, it would be something like this: "in a pedantic MVC system, model objects don't depend on view objects by design, and therefore should not be aware that their methods are used as 'click callbacks'"