There are almost a dozen ObjectiveC interfaces floating around for VisualWorks right now. It's pretty silly to have so many. They seem to range from raw runtime interfaces to full on class building ObjectiveC-connect type beasts. Which approach is best? we don't know really, people will have differing requirements.

John Sarkela has been busy making native print dialogs for MacOSX in VisualWorks 7.7 and as part of that, we need a nice answer to talking to ObjectiveC. So the problem of "which approach" rears its ugly head once more. A group of us had a round table (over skype) about this and decided that we should having the complete ObjectiveC Runtime interface available for developers in the base image. Anything beyond that we deem "ObjectiveCConnect" and is open to discussion and debate as to its actual implementation.

I was given the dubious honor of implementing the ObjectiveC Runtime interfaces for version 1.0 and 2.0. This work is on-going but I've been invested in this ObjC problem for a few years now so I've spent the weekend working on it.

As well as that, I have revisited my previous attempts at an "ObjectiveCConnect" and have merged them together. Here are some of the unique properties each ObjC Connect brings to the table and which ones I chose to go with are bolded:

• Fast interfacing
• Native Smalltalk classes reifying ObjectiveC classes
• Lightweight Smalltalk classes reifying ObjectiveC classes
• Extensive Refactoring Browser intergration
• DoesNotUnderstand proxy pattern for message dispatching
• ExternalInterface methods for message dispatching
• Support for Float and Struct return values
• Support for Callbacks
• Use of the Runtime Type Encoding for interfacing
• Root.ObjectiveC namespace for class lookup

There are probably more tricks that people have used that I'm not mentioning here. So after two days of feverish programming (literally, I have a flu right now), I have two layers: The Runtime layer and an ObjectiveCConnect layer.

I decided to put it to good use. First off, I ported the OpenGL-MacOSX interface to use it. Success, not a hiccup in sight. Next I decided to revisit the classic "Why don't you guys use native MacOSX menus" challenge. I've seen this done in no less than three of the ObjC variations and now I can present the fourth, hastily hacked together with one or two amusing bugs that would need to be sorted out before I shipped it: