ctypes vs cffi pros and cons about rubicon-objc HOT 2 CLOSED

@dimaqq FYI, that isn't Pythonista's "official" Objective-C interface. The built-in one is called objc_util, it's included only with the app, so you probably can't find it online. The one you linked is my attempt at making an Objective-C interface based on CFFI.

The advantage of CFFI is that you can specify types and declare functions using normal C syntax and let CFFI do all the magic. However an issue with CFFI is that it doesn't support dynamic definition of types very well - the only way to define types is from C source with cdef. Objective-C requires a lot of dynamic type creation, because the objc_msgSend function and method IMPs need to be cast to the correct signature, based on the method type encoding. This leads to some relatively lengthy code just to create a type, for example here for structs and unions and here for function pointers. It's also quite slow, because of all the string building and parsing.

Another issue is that all type definitions land in a single namespace. My library automatically cdefs any named structures and unions that it sees in type encodings, which can result in name conflicts. (I'm not sure, but CFFI might even complain if you define the same structure twice with exactly the same fields, which is even more problematic.) The obvious solution would be to use unnamed/anonymous structures and unions instead, but I think if you use an anonymous structure as a function parameter type, anything you try to pass as that parameter will be of the wrong type.

Long story short, I didn't really work on my CFFI-based version much anymore and decided to contribute to rubicon-objc instead.

from rubicon-objc.

Okay that explains it!

from rubicon-objc.