Re: Class OC_PythonObject: no such selector: _cfTypeID
Re: Class OC_PythonObject: no such selector: _cfTypeID
- Subject: Re: Class OC_PythonObject: no such selector: _cfTypeID
- From: "email@hidden" <email@hidden>
- Date: Fri, 4 Jun 2010 21:20:57 +0100
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 (email@hidden)
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:
This email sent to email@hidden