[Mono-osx] Suggested Enhancement for Cocoa.String

Andreas Färber andreas.faerber at web.de
Wed Nov 28 13:46:46 EST 2007


Am 28.11.2007 um 18:53 schrieb marc hoffman:

> Wondering: if "cocoa-sharp at lists.ximian.com" is the *right* list,  
> then how come
> it is not even listed on http://www.mono-project.com/Mailing_Lists  
> anymore
> (which instead now lists a third, google-group based forum)?

Well, the MonoDevelop list wasn't listed there either last time I  
checked.
If as you say it lists such another group, you might want to try  
posting there; that does still not imply that mono-osx is the most  
suitable place.

> I merely wanted to post those files in a place where people will  
> actually *see*
> em. And judging from my subscription to both lists for the past few  
> months,
> those few people that do seem to care seem to be hanging out in mono- 
> osx...?
> Don't get me wrong, but with as little people being active on the  
> Mono/OSX front
> in the first place, why artificially thin the community out even  
> further?
>
> Just a thought.

My point is, the Mono OS X community is not necessarily based around  
Cocoa#. You can write command line apps or daemons, ASP.NET projects,  
SWF apps, Gtk# apps, and embed Mono with or without Dumbarton.

I can't comment on any Google groups but my personal impression was  
that its creation was a reaction to Cocoa#'s lack of maintainance.  
Unfortunately Cocoa# appears to be most attractive as an entry point  
for people new to the Mac, coming from a Windows background without  
Objective-C knowledge - thus it is problematic for such people to  
enhance Cocoa# because that requires a little ObjC understanding, and  
even less people dared to touch the inner workings of the bridge, so  
if things blow you're on your own. On the other hand those that do  
know ObjC will notice a certain performance and memory usage gap  
between the two, likely preferring the "real" one, which is managed in  
2.0 too. So that is a structural problem for the code and the  
community. No idea how to tackle that, we forked our own version for a  
project and are no longer using it by now. I like the idea of a  
managed Cocoa# but in practice it does not scale well. Embedding Mono  
in native ObjC dramatically reduced memory footprint of our app and  
allows me to use the Xcode debugger.

On the original topic, your String patch is not okay as such, you  
should not call Init for a given native object, that overrides the  
original object's contents or possibly even deletes and replaces the  
original object: init* instance methods are always a second-phase  
constructor whose return value needs to be respected and the original  
value must no longer be used afterwards. HTH.

Andreas


More information about the Mono-osx mailing list