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

[Fredrik Olsson]

Bill Baxter skrev:
> Hey there,
> 
> Fredrik Olsson wrote:
>> Bill Baxter skrev:
>>>  > [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?
>>>
>> Hmm... now this is strange, and it took a while for me to grasp it as 
>> well :). Lets take this one:
>> [obj1 sendAction:[obj1 action] to:[obj1 target]]
>> It is actually three method calls, two of them nested.
>> [obj1 action] is calling obj1's method action, and that method returns 
>> a selector, a selector is a method.
>> [obj1 target] is also a method call, but returning an object instance.
> 
> That's very interesting.  Can you also reverse the order of arguments in 
> the call, like to:sendAction:?  Or is that a different method?
>    [obj1 to:[obj1 target] sendAction:[obj1 action]]
> 
> --bb
That would be a different method. The full method declaration is:
- (void)sendAction:(SEL)action to:(id)target;
But the method signature is always typeless and is thus:
sendAction:to:
In practice the type SEL is a char*, and @selector(sendAction:to:) will 
be a char* to the null terminated string "sendAction:to:". What the 
@selector() "macro" does is to guarantee that there is only a single 
pointer to each method signature string so that
if ([item action] == @selector(removeUser:)) { ... }
is guaranteed to work.

Would be nice if you could rearrange the arguments though. But well, 
they are part of the method signature, not named arguments.


// Fredrik Olsson