[Mono-osx] [ANN] objc3-sharp

Eoin Norris e.norris at mac.com
Mon Jun 9 14:38:03 EDT 2008

That seems like remarkable work! I hope to have a play later.

Eoin Norris

On 9 Jun 2008, at 19:32, Laurent Etiemble wrote:


My remarks in the text:

2008/6/9 Jesse Jones <jesjones at mindspring.com>:
> On Jun 8, 2008, at 11:24 PM, Jérôme Gagnon-Voyer wrote:
>> When you say it's similar to Mono objc-sharp library, do you talk
>> about monobjc? http://www.monobjc.net/
> No, I was talking about objc-sharp.
>> Can you describe how is it faster and easier?
> I confess this is the first time I've seen monobjc. It certainly looks
> better than objc-sharp, but I'm not sure its design is better than
> objc3-sharp (although it does look considerably more mature). Here are
> some points of comparison (which are based on a few minutes of
> inspection of the monobjc source, so take them with a grain of salt):
> 1) In monobjc methods are called like this:
> Class cls1 = Class.GetClassFromName("TestClass04");
> int result = ObjectiveCRuntime.SendMessage<int>(cls1, "TestWithA:b:",
> 789, 345);

The syntax above is the one used internally (or in very specific
cases). A method call can be as simple as:

TestClass04 instance = new TestClass04();
int result = instance.TestWithAB(789, 345);

> With objc3-sharp you would instead write this as:
> Class cls1 = new Class("TestClass04");
> int result = (int) cls1.Call("TestWithA:b:", 789, 345);
> or even nicer:
> int result = (int) Native.Call("[TestClass04 TestWithA:{0} b:{1}]",
> 789, 345);
> objc3-sharp will also let you chain calls (i.e.
> foo.Call(...).Call(...) which I don't think monobjc supports.

Monobjc does not support chain calls.

> 2) objc3-sharp calls are very efficient. Basically all that they do is
> marshal arguments into buffers and call into a small native library
> where libffi takes care of the platform calling conventions. monobjc
> is much much more complex. So complex, that I can't even figure out
> what it's doing when it makes a native call.

As Monobjc is a pure .NET bridge, the marshaling is done entirely
through runtime generated proxies and P/Invoke. The platform
conventions are handled according to the processor and the Objective-C
runtime version.

> 3) objc3-sharp handles exceptions well no matter where they are
> raised. If you call a native method and it raises NSException a
> CocoaException will be thrown when the native call returns. The
> CocoaException has a property which allows you to get the original
> NSException. If you call a native method which winds up calling a
> managed method and that throws, then the managed exception is
> serialized into an NSException which is then raised in the native glue
> library. If that exception makes it back to managed code a
> TargetInvocationException is thrown where the inner exception is the
> original exception.
> As far as I can tell monobjc doesn't bridge exceptions at all.

Exceptions are not handled directly. There is a workaround that
involves the NSExceptionHandler class, which allows the wiring of a
custom exception handler.

> 4) monobjc doesn't seem to do anything to simplify reference counting.
> objc3-sharp relies on the GC to know when to release objects which
> dramatically simplifies reference count management.

As Monobjc is targeted to both Objective-C 1.0 and Objective-C 2.0,
there is no link to the GC (maybe in the future). For the moment,
reference counting is the way to go (it works the same as in
Objective-C with retain/release).

> 5) objc3-sharp  is way way simpler than monobjc. This seems to be
> because objc3-sharp only supports 10.5, libffi plus a small native
> glue library makes marshaling easy, and objc3-sharp has a narrower
> focus: it's designed just to enable interop with Cocoa, not wrap the
> entire Cocoa framework.

Monobjc was build to run on both Mac OS X 10.4 and 10.5. Its spectrum
is also very wide as it aims to provide a nearly complete coverage of
the most used Mac OS X frameworks (Cocoa, Webkit, QuickTime,
DiscRecording, etc).

> <http://code.google.com/p/objc3-sharp/wiki/Usage> has some additional
> code snippets if you're curious.
>  -- Jesse
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
Mono-osx mailing list
Mono-osx at lists.ximian.com

More information about the Mono-osx mailing list