Cocoa# (CocoaSharp) appears to be the planned language for working with Mono (dotNet clone) on OS X.
Release 1.0.6 (February 18, 2005): http://www.mono-project.com/news/index.html#2-2f17-2f2005-202-3a00-3a00-20PM The OS X Mono framework now includes a functional Cocoa#.
Release 0.1 (August 12, 2004): http://www.mono-project.com/using/cocoa-sharp.html Screen shots: http://www.osnews.com/story.php?news_id=8023
“Using Mono on Mac OS X” (Jul 15th, 2004) [http://www.mono-project.com/using/macos.html] provides considerable detail on installing the Mono tools on OS X.
Cocoa# isn’t a language but an API. It gives access to the Cocoa set of libraries (and probably bridges to the whole ObjCRuntime) from C# so you can create NSDictionaries, manipulate NSUserDefaults, use Cocoa’s DistributedObjects etc. all within C#. Since CSharp also has it’s own runtime (much like Java) and Cocoa doesn’t exist within that runtime, the people working on CocoaSharp would have to build bridging between the two runtimes… This is why it’s great that ObjC boils down to C, and exposes the C interface that it turns into (ObjCRuntime). Note that this bridging will probably be one-way allowing access to Cocoa from C# (oh and other .Net languages like… Visual Basic .Net)but not allowing access to the .Net libraries from ObjC. The thought of coding a Cocoa app in VisualBasicDotNet chills me to the bones. It’s just wrong people!
Well… I did, once, with CocoaSharp 0.1. It works quite well (it’s got autocompletion) :D – l0ne aka EmanueleVulcano
I’m excited about this, since I like the CLR notion of being able to write libs in several differnet languages and have them all link together cleanly. However, looking at the Cocoa# 0.1 sample code, Cocoa# suffers from the same issue as the Cocoa/Python binding: having method names be mangled to support ObjectiveC’s interleaving of parameter names and values.
So a message like -(void) doSomethingWith: (id) someObject and: (id) anotherObject whatever: (int) value; becomes the less graceful doSomethingWith_and_whatever( id someObject, id anotherObject, int value );
Not that this is a deal breaker, but it’s a little clumsy. Nevertheless, I’m excited. I installed it and the start-up speed to run an app is actually quite decent. No 20 second wait while the JVM starts up ;)
The real question is wether we’d need a SWIG type binding generator to allow Mono to use custom ObjectiveC classes. I don’t know, but I haven’t read the documentation in sufficient detail. It would be amazing if the bindings were automatic. The logical thing to do would be to write an ObjectiveC CLR compiler, so your existing code could compile down to bytecode and work automagically. I doubt that’s going to happen any time soon, however, considering the memory management conflicts.
–ShamylZakariya
There’s a parallel project - ObjC# (also in the mono cvs), that binds in the opposite direction – allowing ObjectiveC code to access CLR objects and libraries. The primary focus seems to be on CocoaSharp right now, however, since it seems to be of wider interest (there are more people who would like to access cocoa from clr languages than there are people who want to access the .net libraries from objc).
Also, they are planning on addressing the ugly method-names problem, at least to some extent – the autogenerated names will be overridden for the apple libraries in order to make them fit in with the rest of the system (along with a few other tweaks, like replacing get_/set_ methods with properties, etc). The plan is to make Cocoa# look natural for .net programmers, and ObjC# look natural for ObjC programmers. The mono guys already have a fair bit of experience with this sort of thing, since similar things had to be done for Gtk# (the managed wrapper around gtk+, which is an object-oriented gui api written in straight C (to the extent that you can do OO with C, anyway… lots of pointer-cast polymorphism)). Obviously, anyone wanting to generate a wrapper for libraries that haven’t already been wrapped will have to expend some effort in order to map from one to the other, but from what i’ve seen of the tools used for gtk#, they should be able to make it fairly painless.