In short, Yes. But not without some pain.
You can grab an example of the Python and Ruby bridges working together in a Cocoa application from either this downloadable zip or from this Subversion repository (in case something actually changes).
Specifically, RubyCocoa and PyObjC both assume that nothing else might have loaded the dynamic libraries that are automatically generated by the gen_bridge_metadata script. So, either bridge will quite happily attempt to load
/System/Library/Frameworks/Foundation.framework/Resources/BridgeSupport/Foundation.dylib and then barf mightily when the other bridge has already loaded the same dylib.
The example is rife with silliness related to catching the resulting exceptions and ignoring them. Worse, the fallout is such that
from Foundation import * doesn’t actually cause the Objective-C classes to be defined within the importing module.
There is a back door —
objc.lookUpClass() — but this is yet further evidence that, at this time, mixing these two languages in a single Cocoa application is not anything more than a silly hacque (as the SVN repository subdir indicates).
What does it do?
Not much, really.
- Start with RubyCocoa Application Template (because I can deal with brokeness in Python, I wanted to start with something working in Ruby)
- NSApp Delegate written in Obj-C
- Finish loading hooks used to bootstrap PyObjC/Python (with gross exception ignoring goofiness related to the dylib)
- Bind a table view to an array of dicts where each dict has the key “name” leading to a string value bound through array controller.
- Array controller bound through app delegate method.
- App delegate returns array of dictionaries by calling python based NSObject subclass.
- Python based NSObject subclass composes an array of dictionaries (all python) from a combinatio of Python strings and Ruby strings by calling an instance of a Ruby based subclass of NSObject.
Very little code. Lots of moving parts. Some gears grinding. Maybe even a gear tooth or four missing. Enjoy.