In particular, Ronald’s post gives an excellent overview of the new features and capabilities of PyObjC.
There is a theme: “greatly tighten the integration with Mac OS X in a more consistent and less special-cased fashion”.
Read on for details:
To that particular end, PyObjC 2.0 — like recent releases of RubyCocoa — embraces the metadata generated by BridgeSupport. BridgeSupport allows a machine-readable description of APIs — be they C or Objective-C — in XML, with support for 32 vs. 64 bit differences. PyObjC and RubyCocoa use the BridgeSupport metadata o make calls from the interpreter into the native ABI on the system. Succinctly; BridgeSupport allows for data driven calls through to APIs that were previously special cased either per call site or per bridge implementation.
BridgeSupport is included with Leopard, including documentation. See the gen_bridge_metadata and BridgeSupport man pages. As well, a full-text search in Xcode’s documentation viewer reveals another chunk of documentation.
At the other end, Leopard also includes a vastly improved version of libffi. Beyond a number of bug fixes and actually having a man page now, libffi also correctly supports both 64 bit ABIs available in Leopard; ppc64 and x86_64.
Specifically, PyObjC and RubyCocoa use the BridgeSupport generated metadata to construct native calls via the FFI API.
Leopard provides metadata for most of the frameworks and CF-or-higher level APIs on the system. Not all; some APIs can’t be expressed via the metadata yet (C++, for example).
The list is quite long:
Not all of these APIs are available directly in PyObjC. Yet. Some require a touch of glue. If “import FrameWork” doesn’t work, glue will be needed. More on the glue in a later post.
Both the metadata listed above and the tools to generate the metadata are provided without requiring the dev tools to be installed. Dev tools are necessary if metadata generation also creates a dylib that contains any bits — static inline functions, for example — that cannot be expressed purely in XML.
And, of course, it is quite straightforward to generate bridge metadata for your own Objective-C and C APIs. It is just a matter of running the
gen_bridge_metadata utility against your APIs. Exceptions in the form of XML that overrides the automatically generated XML can be provided, too.
In essence, Apple is taking a bit of a different approach to embracing and supporting scripting languages to develop native applications.
Instead of trying to crowbar the scripting language’s syntax on top of whatever VM-du-jour happens to be running on the platform, BridgeSupport — and, by integration, Leopard — provides all of the metadata necessary to allow the native scripting language to be used to create native applications through a bridge between the two. Given that BridgeSupport works just fine on Tiger, this isn’t something limited to Leopard.
The metadata is intended to be a resource for use beyond bridging. Most frameworks on the system provide two chunks of XML BridgeSupport metadata; succinct and full. The succinct version contains all of the metadata not provided by the Objective-C runtime (which provides about 80% of what is necessary to do full fidelity calls in / out of Objective-C via libffi). The full version contains just that, the full metadata required to describe the APIs of the framework, including all the bits that could be gleaned at runtime.
Already, the BridgeSupport API metadata is used for more than just bridging languages. For example, Xcode offers Objective-C method name completion in standalone Python and Ruby source files — no project necessary — by leveraging the BridgeSupport metadata!
I am looking forward to seeing the imaginative ways with which developers leverage the BridgeSupport metadata. Certainly, there is more work to be done, but it should provide a very strong foundation for innovation as it is now!
Once PyObjC 2.0 move over to the public repository, I fully expect that development on 2.0 will continue beyond what ships in Leopard. As a consumer of PyObjC, it will be up to you to decide whether you want to stick with what is in Leopard or track PyObjC development.
For most folks, what is in Leopard will be just fine — it works great for building Cocoa applications.