Dynamic binding -- Qt's Signals and Slots vs Objective-C

[Lutger]

Josh Stern wrote:
<snip>
> The issues of what has to be decided at design time, compile time, and 
> run time in order to use signals and  slots are important. 
> Requiring inheritance from QObject for some things is one kind
> of strong restriction, and requiring connections specified at
> compile time is another.  There are language vs. library issues
> involved here.  A (the?) key language feature seems to be the question of
> what kind of support does the language provide for making it easy to
> attach a "hook" to a given function (where hook means roughly "now
> Mr.Ffunction, from now on, before you exit, please call this other
> function I'm about to tell you about with your return value as
> its input and maybe some other info like a pointer to your object in case
> you are a member function"). I agree with the implicit point made by the
> slotsig guy that part of this mechanism ideally should give the user
> options about thread-safety and thread-locality. Seems like if the
> language provides a really good hook mechanism, a lot of convenient
> library stuff can be built on top to taste. Intuitively it seems like D's
> system of Boxs and delegates could be put to good use towards finding
> attractive possibilities within the library problem design space, and
> having GC to eliminate most ownership issues makes many solutions a lot
> simpler.   

Yes, although I would not see requiring connections at compile time as a 
  restriction, I would file this under 'feature' as it enables 
compile-time type checking. It's a choice really, connections at runtime 
are more flexible but less safe and incur performance cost. Requiring 
inheritance (but more so custom preprocessor) in QT is needed to make up 
for lack of introspection in C++.
Ideally you'd have both systems available to choose the appropiate one 
for what you want.