[Cocoa-sharp] The State of the Art

[Andreas Färber]

Am 23.02.2007 um 22:14 schrieb Edward J. Sabol:

> Todd Schavey wrote:
>> I've yet to see [any] 'leadership' step forward.
> [...]
>> I still hold a lot of promise with CocoaSharp....I just wish whatever
>> leadership is on the seemingly sinking ship would crawl out from the
>> rock there under and give a little direction.
>
> Todd, I don't think that's a fair assessment. While I do tend to  
> agree that
> the project could use more leaders and more activity in general, I  
> think you
> must have missed or forgotten Geoff Norton's e-mail to
> <cocoa-sharp at lists.ximian.com> on 12 Feb 2007. I'll include a copy  
> here for
> easy reference (more discussion from me below):

Edward, this is not very helpful. Independent of what Geoff emailed  
now, since 2/2006 Cocoa# sadly is de facto "dead" - not because  
anyone is officially declaring it dead but rather because it is no  
longer actively maintained. And by that I mean reviewing patches and  
committing code. As I understood him, for personal and professional  
reasons he is no longer using a Mac and therefore unable to continue  
his great pioneering work as before, so calling it "lack of  
leadership" is not fair.

True are some facts: Several patches were not committed since that  
time. I discovered severe bugs in Cocoa# and invested lots of time to  
rewrite large parts of its core bridge to make it work, nothing was  
done about that, also no improvements for maintainability of the  
bridge code. I did discover (and post) a simple way of having the  
menu display correctly through a symlink at the *correct* location,  
this is still being silently ignored. Then as additional pieces of  
the puzzle...
- launching the Mono runtime instead of a native Cocoa executable  
brings in problems in some areas (e.g. AppleScript),
- tracking object deallocation for each and every unmanaged NSObject  
instance brings in even more performance issues than all the actual  
messaging calls themselves,
- retaining each and every object bloats up the memory usage (but is  
required to avoid segfaults),
- we are unable to catch ObjC exceptions,
- we are unable to access global ObjC variables,
- Mono's GC is not fully working with the Cocoa# approach (no  
disposing/finalization when app terminates),
not to mention that, obviously, adding all the missing classes,  
methods and properties is inconvenient.

The reason why I personally started using Cocoa# is because I like  
the C# language and the .NET/Mono class libraries (and had no clue  
about Objective-C). Going back to complete but generated classes and  
therefore ObjC-ish class libraries is no option I would recommend to  
any one of you, we already had that. If you want to use such a  
library then learn Objective-C instead.

The core problems with Cocoa# are at the bridge level - C# is simply  
different from Objective-C in many ways including inheritance, which  
makes it difficult to map between the languages. And as another  
aspect, some Cocoa frameworks don't like NSObject being posed as and  
start jamming the console with warnings.

I'm not saying Cocoa# was bad - it's a very nice concept in theory.  
But from my point of view we don't need lots of people volunteering  
to write documentation in its current state. We need improvements to  
Cocoa# itself first, making it more usable - people actually  
contributing to improve the inner workings of Cocoa# and some  
workflow to get such contributions into SVN trunk in an orderly and  
timely fashion.

As you might have read I have been able to write an Xcode plugin  
using my version of Cocoa# in a relatively elegant way that works  
around many of the problems a pure Objective-C plugin encounters with  
the currently private Xcode API. So there is potential for Cocoa#,  
even if an Objective-C GUI application with embedded Mono is faster  
and less error-prone at the moment.

Some ideas to think about might be:
* Can a p/invoked unmanaged ObjC library help to catch unmanaged  
exceptions and bridge them as managed exceptions?
* Might it be useful to replace the launcher script and mono  
executable with a Cocoa#-specific ObjC executable that embeds Mono?  
(I use atexit to invoke Mono's cleanup function in my app)
* creating native stub libraries embedding Mono for using Cocoa# in  
more than just applications, for example Automator actions, Widget  
plugins, Spotlight importers etc.

Andreas