[Mono-osx] MacOS bindings and MonoDevelop.
jesjones at mindspring.com
Thu May 14 13:58:52 EDT 2009
Fwiw here are some places where I think mobj/mcocoa are better than
* 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
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
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:
More information about the Mono-osx