[Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[bbum@mac.com]

On Wednesday, October 16, 2002, at 05:27 PM, Bob Ippolito wrote:
>> rt.call() concatenates the method name as "drawSelfAtPoint: color:  
>> withSize:". Then the runtime sends a message to the object to perform  
>> the selector "@sel (drawSelfAtPoint: color: withSize:)", and the  
>> object says, it can't.

The two are identical in the context of @selector(), but not  
NSSelectorFromString.   Odd.  A bugreport.apple.com report has been  
filed.

Consider this output:

2002-10-16 17:42:19.198 bar[9636]  
pathForResource:ofType:inDirectory:forLocalization: ==  
pathForResource:ofType:inDirectory:forLocalization:
2002-10-16 17:42:19.232 bar[9636]  
pathForResource:ofType:inDirectory:forLocalization: != pathForResource:  
ofType: inDirectory: forLocalization:

 From this code:

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   SEL sel1 =  
@selector(pathForResource:ofType:inDirectory:forLocalization:);
   SEL sel2 = @selector(pathForResource: ofType: inDirectory:  
forLocalization: );

   SEL sel3 =  
NSSelectorFromString(@"pathForResource:ofType:inDirectory:forLocalizatio 
n:");
   SEL sel4 = NSSelectorFromString(@"pathForResource: ofType:  
inDirectory: forLocalization: ");
   if (sel1 == sel2)
     NSLog(@"%@ == %@", NSStringFromSelector(sel1),  
NSStringFromSelector(sel2));
   else
     NSLog(@"%@ != %@", NSStringFromSelector(sel1),  
NSStringFromSelector(sel2));

   if (sel3 == sel4)
     NSLog(@"%@ == %@", NSStringFromSelector(sel3),  
NSStringFromSelector(sel4));
   else
     NSLog(@"%@ != %@", NSStringFromSelector(sel3),  
NSStringFromSelector(sel4));
   [pool release];
   return 0;
}

Seems like a bit of a discontinuity between the way the two work.

>>
>> Am I understanding you correctly? Because, the way I see it, this is  
>> likely to encourage runtime errors (unknown selector).
>
> That's not a case of ambiguity, that's just Programmer Error.  Unknown  
> selector is what they *should* get for issuing the selectors in an  
> incorrect order.  Notice that he's using ordered list arguments, not  
> dictionary arguments for his call function.

In that you are correct -- an array of arguments could be interpreted  
in this fashion.

However, I completely fail to see how...

     rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")

... is cleaner/clearer/better than...

     obj.drawSelfAtPoint_color_withSize_(p, c, s)

b.bum