[Mono-osx] mobj discussion

[Edward J Sabol]

>>> * Objective-C method names are really weird and don't map well to .NET
>>> naming conventions. For example, the objective-c method
>>> observeValueForKeyPath:ofObject:change:context: is mapped to
>>> ObserveValueForKeyPathOfObjectChangeContext in Monobj which is a really
>>> confusing name to read. I originally did the same in mcocoa but I wound
>>> up changing them to observeValueForKeyPath_ofObject_change_context which
>>> is much easier to read.
>>
>> The MonObjc version is closer to the .NET design guidelines.
>> 
>> But when it comes to naming of methods, they are both terrible options.
>
> Yes, neither one is a good option, but I think it is a lot better for
> the wrapper classes to preserve the real method names in so far as
> possible instead of trying to torture them into fitting the .NET
> guidelines.
[...]
> That's a difficult question. There's clearly value in providing a
> limited number of alternatives like enumeration via IEnumerable in
> addition to the normal cocoa mechanisms, but flat-out hiding cocoa
> functionality behind a .NET style wrapper seems wrong to me. It's a
> lot simpler if the managed code is simply a bridge into cocoa so you
> can continue to use apple's documentation and examples without
> worrying about how they map onto your semi-cocoa wrapper.

Hi. I just thought I'd toss my 2 cents worth in as a bystander developer who
has done some work with Cocoa# back in the day but hasn't done anything
substantial with either Monobjc or mobjc.

FWIW, I strongly agree with Jess's approach on both of the above points. I
strongly prefer that the method names and such to match Apple's even if they
violate .NET guidelines. As a developer, whenever I need to figure out how to
do something that needs to utilize Cocoa, I'm going to refer to either
Apple's sample code or Apple's documentation or code gleaned from discussions
with other Mac developers. The less I have do to modify such code to work
with Mono the better! This isn't an issue of a lack of documentation. It's
just a realistic view of how Mac developers will approach Cocoa development
with Mono.

Also, it seems to me that the main advantage that Monobjc has over
mobjc/mcocoa is that it works with Mac OS X 10.4.x. It pains me to say this
since I still use 10.4.11 myself on at least one computer, but I don't think
that should be a dealbreaker. 10.6 will be released in 4-5 months at most, so
10.4's time is almost up. Also, from what I understand, mobjc/mcocoa is based
on Apple's endorsed bridging technology (which is already used by other
languages such as Python and Ruby, I believe), resulting in a cleaner and
faster implementation.

+1 for mobjc/mcocoa

Later,
Ed