[Mono-osx] MacOS bindings and MonoDevelop.

[Jesse Jones]

Fwiw here are some places where I think mobj/mcocoa are better than  
Monobj:

* Like NObjective mobj bridges exception across managed and unmanaged  
code so either side can throw and either side can catch. This seems  
pretty important to me for writing reliable software and also aids  
development (e.g. with Monobj if the native code throws it seems to be  
logged and then ignored, but there is no stack trace).

* mobj's implementation is much simpler than Monoobj. I'm not sure why  
Monobj is so complex but part of it I think is that Monobj supports  
both 10.4 and 10.5 whereas mobj only supports 10.5 which has better  
support for bridges. mobj also leans on libffi when calling native  
code which simplifies the code a fair amount.

* mobj has a fast path which completely bypasses libffi. 84% of the  
foundation methods in mcocoa use the fast path and 77% of the methods  
in appkit do so. This works out great for mcocoa because libffi is  
quite a bit slower than I had hoped (although iirc Eugeny's benchmarks  
showed it a bit faster than Monobj). Note that the benchmarks that  
Eugeny posted in the past only hit mobj's slow path so they are not at  
all indicative of real world speeds.

* Objective-C method names are really weird and don't map well to .NET  
naming conventions. For example, the objective-c method  
observeValueForKeyPath:ofObject:change:context: is mapped to  
ObserveValueForKeyPathOfObjectChangeContext in Monobj which is a  
really confusing name to read. I originally did the same in mcocoa but  
I wound up changing them to  
observeValueForKeyPath_ofObject_change_context which is much easier to  
read.

This also allows for a nice separation between methods which wrap  
cocoa and those added by the bridge (which can use the standard .NET  
naming conventions). In addition it allows mobj to automatically  
register methods with the objective-c runtime so you don't have to  
litter your code with  
[ObjectiveCMessage("observeValueForKeyPath:ofObject:change:context:")]  
like you have to do in Monobj.

* Monobj distributes the wrapper libraries in binary form whereas  
mcocoa generates them as part of the build process. This means that  
it's a lot easier to see what mcocoa is doing and makes it possible to  
generate wrappers for other objective-c frameworks.

* Tools like top think that every Monobj application is named "mono"  
which is pretty annoying. In mobj they are named after the app bundle.

* One of the Monobj users reported that "apps can just quit and it can  
be hard to work out why." I haven't seen anything like this with mobj,  
It seems very solid. The only times I have seen anything like this is  
when object reference counts are mismanaged and even there you get a  
stack trace which points you to the right neighborhood.

If anyone wants to look at mobj or mcocoa more the links are:
http://code.google.com/p/mobjc/
http://code.google.com/p/mcocoa/

   -- Jesse