You made a good point in the fact that Objective-C, as a subset of C, can call C/C++ APIs without much difficulty. Ruby and Python can't do that as easily without writing/generating an extension or dealing with the dynamic linker API. But we are working on a new mechanism to make the non Objective-C frameworks accessible from Ruby and Python without no cost. This is based on metadata files and briefly explained in the "RubyCocoa 1.0 Sneak Preview" page. We use this to cover everything that can't be retrieved at runtime (including Objective-C things like informal protocols, and very recently, inline functions). This mechanism would also be public so that 3th party developers could cover their own frameworks.
Secondly, regarding the Objective-C calling syntax, it is true that translating the selectors into Ruby and Python calls isn't an easy job. The PyObjC guys came up with this underscore-based syntax a long time ago, and the RubyCocoa team just followed them since. This syntax should be good enough for most cases (the long selectors are pretty rare). RubyCocoa has nevertheless this new #objc_send API that you can use to explode your selector, but it's still not perfect. We used to have alternative syntaxes (based on inline Hash) but we decided to deprecate them as they were not reliable enough. We have been discussing with the Ruby core team about adding "keyed-parameters" to a future Ruby version and both of us are very interested in doing this. For the moment we are just discussing it.
by Laurent Sansonetti — Feb 20
Nice post! Just a few additions.
You made a good point in the fact that Objective-C, as a subset of C, can call C/C++ APIs without much difficulty. Ruby and Python can't do that as easily without writing/generating an extension or dealing with the dynamic linker API. But we are working on a new mechanism to make the non Objective-C frameworks accessible from Ruby and Python without no cost. This is based on metadata files and briefly explained in the "RubyCocoa 1.0 Sneak Preview" page. We use this to cover everything that can't be retrieved at runtime (including Objective-C things like informal protocols, and very recently, inline functions). This mechanism would also be public so that 3th party developers could cover their own frameworks.
Secondly, regarding the Objective-C calling syntax, it is true that translating the selectors into Ruby and Python calls isn't an easy job. The PyObjC guys came up with this underscore-based syntax a long time ago, and the RubyCocoa team just followed them since. This syntax should be good enough for most cases (the long selectors are pretty rare). RubyCocoa has nevertheless this new #objc_send API that you can use to explode your selector, but it's still not perfect. We used to have alternative syntaxes (based on inline Hash) but we decided to deprecate them as they were not reliable enough. We have been discussing with the Ruby core team about adding "keyed-parameters" to a future Ruby version and both of us are very interested in doing this. For the moment we are just discussing it.