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

[Bill Baxter]

Howdy.

Fredrik Olsson wrote:
> How Obj-C Cocoa does it:
> 
> Each object can have an action and a target. 

By this you mean each GUI widget can have an action and target, right?

> An action is an event that 
> is signaled at run-time, and the target is an object instance to call. 
> If target is nil (null) then the action will be sent to the responder 
> chain, instead of a predestined object.

> The responder chain is implemented in the NSResponder protocol 
> (Interface) and will send the action down the controllers is logical 
> order acording to how windows are stacked, ending up in the 
> NSApplication instance if no one else is interested. 

So it forms a kind of tree or funnel with leaves being widgets, and the 
root being the NSApplication instance.

> This make sure that 
> if a single menu item (OSX == one menu you know :) ) has nil as target, 
> then the topmost window will get a chance to respond first, and yet the 
> same item will work for all windows.

Don't really follow you there.  Why does the topmost window get the 
first chance?  Just before you said it went up a chain, so it seems like 
the immediate container window of the item would get the first chance, 
and eventually the topmost window will get a chance.

Anyway, this part of your description seems much more Cocoa than 
Objective C.  I.e. it seems independent of the language itself, more or 
less just the classic "chain of responsibility" pattern.  Just something 
implemented on top of the messaging sys provided by Obj-C.

> You connect an action/target like this:
> [obj1 setAction:@selector(valueChanged:)];
> [obj1 setTarget:obj2];

> And you can later "emit" the action using:
> [obj1 sendAction:[obj1 action] to:[obj1 target]];
> which will cause the valueChanged: method of obj2 to be performed. In 
> reality most classes have shortcuts such as sendAction, and even more so 
> you rarely need to care about sending manually at all.

Ok, I'm trying to grok these message things now.
It looks like there's no distinction between method names and call 
parameters.  Like here:
 > [obj1 setAction:@selector(valueChanged:)];
setAction looks sort of like a method with parameter being a selector. 
But then here:
 > [obj1 sendAction:[obj1 action] to:[obj1 target]];
it looks like there are two methods, 'sendAction' and 'to'.
And I take it [obj1 action] is a named attribute lookup, similar to a 
QProperty?

Fredrik Olsson wrote:
 > Lucas Goss skrev:
 >> Bill Baxter wrote:
 >>
 >>> Gotta go, but I think some sort of built-in dynamic dispatch
 >>> mechanism like this would have to be part of my "dream language".
 >>>
 >> I think I'm of the same opinion. I'm just starting to learn Obj-C now...
 >
 > I want to agree as well. But hmm... how D and Obj-C tackles OOP is so
 > very different that I can not see any way to merge the two.

Is it really so difficult?  Maybe I just don't understand how Obj-C 
works well enough, but in Obj-C you have both regular C function calls 
(do_something(foo)) and message passing ([obj doSomething:foo]) and the 
user decides which paradigm to use at what time.  Similarly in an Obj-D 
you could have regular method calls (obj.do_something(foo)) and 
messaging calls ([obj doSomething:foo]).

It seems like it could work more or less the way slots do in Qt.  If I have:
# slot:
#   void callMeLater(int val);

In a Qt program, then callMeLater is a valid method that can be called 
like any other method.  But it is *also* callable via dynamic lookup 
using QObject's under-the-hood moc-generated mechanisms. I don't see why 
a similar idea wouldn't work for adding a touch of Obj-C to D.

 > So just as you can not seamlessly mix C++ classes and Obj-C classes in
 > Objective-C++, I can not see how D classes and Obj-C classes could be
 > mixes seamlessly in any practical way.

Maybe I'm just not seeing the full scope of how Obj-C works yet.  But 
nothing I've heard so far seems like an insurmountable hurdle.

It just doesn't seem a very attractive proposition to me to have to 
decide at initial design time whether my class will have regular methods 
or use dynamic messaging.  I may know I want to start out with one or 
the other, but then I want my static class to recieve a particular 
message from a GUI.  I guess these guys at Apple have given it some 
thought with Obj-C++, but my initial reaction was that keeping the types 
of classes completely separate must be some kind of corner cutting to 
get the thing out the door quickly, or perhaps having something to do 
with preserving C++ compatibility.

--Bill