[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