[Mono-osx] Suggested Enhancement for Cocoa.String

marc hoffman mh at elitedev.com
Thu Nov 29 07:08:20 EST 2007


> 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; 

Well; i've posted to said list a few times in the past, it's basically a big

> that does still not imply that mono-osx is the most
> suitable place.

Given that even Geoff just told me he wasn't even aware of a separate
cocoa-sharp list, i'd say that imho mono-osx comes pretty close to being the
suitable place, as of now ;)

> 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 see your point, and i would agree if this list would see 250 messages a day.
However, given the few messages a week here and the virtually non-existent
traffic in the other list, does it really make sense to have theme split? If
anything, it seems to me it would *discourage* people from suing Cocoa#, as they
don't see it here.

Case in point: I've heard back from a couple of people via direct mail, which
said "woah, i didn't even know there was mono-osx, i thought Cocoa# was dead coz
nothing was happening on the other list".

I think if we want to improve adoption of Mono on OS X (and improve Cocao#,
too), the goal should be to consolidate supporters, not spread 'em apart. But
that's just IMHO, of course.

> 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.

Ok, sorry if i need to be a pain and keep coming back to this but: so you're
telling me you weren't even aware of the google group, and STILL above you
recommend i should have posted there instead (where neither you nor anyone else
relevant to the project would have even see the files)? Sorry, i don't get it.

> 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.

I assume you mean the Menu fix, where i added the ctor. Thank for clarifying,
that makes sense. As a matter of fact, i see the latest version in SVN already
has the empty ctor(IntPtr), so there's no action needed for the Menu...


marc hoffman

RemObjects Software
The Infrastructure Company

More information about the Mono-osx mailing list