Hi Hamish On 4 Jun 2010, at 20:40, has wrote:
> Jonathan Mitchell wrote: > >> On occasion I see my PyObjC scripts generating the following: >> >> Class OC_PythonObject: no such selector: _cfTypeID >> >> My app executes user supplied scripts and the error appears to be generated >> under a number of circumstances >> including inadvertently calling an object function with the wrong number of >> arguments. >> >> How should this error be interpreted? >> Is it indicative solely of argument mismatch? > > Hi Jonathan, > > The PythonMac-SIG mailing list is the probably the best place to ask > Python-/PyObjC-specific questions: > > http://mail.python.org/mailman/listinfo/pythonmac-sig > Funnily enough I have just subscribed. > >> RubyCocoa is much more informative when inadvertently calling a function >> with the wrong argument count : >> wrong number of arguments (0 for 2) > > > RubyCocoa maps ObjC method names to the same Ruby method name when there are > 0 or 1 args given, e.g. -foo and -foo: both map to #foo. I discovered that just today. both OSX::NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_(2, self, :timerFired, nil, true) and OSX::NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats(2, self, :timerFired, nil, true) are valid. The ruby sig for the callback has to be as follows though: def timerFired(timer) > > PyObjC, OTOH, maps -foo to foo and -foo: to foo_, so they are indeed > different method names in Python. > > Thus, the PyObjC 'no such selector' message is technically correct, if not > overly helpful, since -foo and -foo: are different names in ObjC too. Thanks, it makes sense now. I had got it into my head that the object was not getting instantiated for some reason. I have been coding up dynamic invocation of PyObjC classes loaded from file and had seen this error repeatedly(!) until I managed to get things working. I had throughly confused myself as to the possible nature of its origin. > > I guess that's the nature of these bridges: it's not enough to understand how > the local language (Python/Ruby) works, you need a good understanding how the > target platform (ObjC runtime) and the bridge between the two environments > (PyObjC/RubyCocoa) operate too. Although you could always submit a feature > request asking for more 'intelligent' error reporting from the bridge in > response to known common user errors such as forgetting the trailing > underscore in PyObjC, e.g.: "no such selector: _cfTypeID (did you mean > _cfTypeID_?)". To me it would seem that the bridge code should try and report errors in an as agnostic a form as possible. This error has its feet firmly on the ObjC side of the bridge. The bit about understanding the bridge between the two environments is definitely the most challenging aspect. The ASObjC, PyObjc and RubyCocoa bridges all have their peculiarities. But given the complexity of the process (though dimly perceived) it is remarkable that the bridges are as robust and flexible as they are. Thanks and regards Jonathan _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
