[Mono-osx] Suggested Enhancement for Cocoa.String

[marc hoffman]

Andreas

> 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
/dev/null.

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


Yours,

marc hoffman

RemObjects Software
The Infrastructure Company
http://www.remobjects.com