[Mono-osx] mobj discussion

[marc hoffman]

Jesse,

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

agreed, especially for those of us who actually do develop on Objetive- 
C as well (or, for that matter, just want to be able to use Apple docs  
wihtout being completely lost because the APIs are, essentially,  
completely different).

i think the big questions is, what's our goal here: do we want the  
Cocoa API exposed (ie existing classes callable and usable from Mono),  
or do we want a high level wrapper (like, say, what .NET is for  
Win32). For the first goal, imho it makes little sense mto mangle the  
API names beyond recognition just to fit .NET naming rules - because  
you'd essentially end up with a *different* API. For the second, i'm  
not sure if that's sensible, since Cocoa - different then Win32 -  
already is a very high-level and sophisticated API.

so my vote towards something (still preferably Monobjc, imho) that  
preserves the the Cocoa API.

i do more coding in Obj-C then i do in Mono, and i, for one, don't  
really want to learn a "new" API, to use Cocoa from Mono.

>> For example, after reading the docs for it seems like this should be
>> exposed as an event with a signature like this:
>>
>> 	public ValueChangedEventArgs : EventArgs {
>> 		public string KeyPath { get; }
>> 		public object ChangedObject { get; }
>> 		public Hashtable Changes { get; }
>> 	}
>> 	delegate void Change (object sender, ValueChangedEventArgs vc)
>>
>> So code that consumes this would then do:
>>
>> 	class.Changed += delegate (s, args){
>> 		Console.WriteLine ("Change at {0}", args.KeyPath);
>> 	}
>
> 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.

indeed. especially (i seem to be missing the context for Miguel's  
code, so i'm not sure if that's what he's referring to with this), i'm  
not sure if it is a good idea to turn delegates in to .NET events (as  
iirc some of Cocoa# does), as (Cocoa) delegates work vastly different  
than .NET events, even if they solve a similar goal. For one thing, i  
can assign a single delegate to handle 37 different callbacks on the  
same object. opposed to having to assign 37 separate events.

>>> This also allows for a nice separation between methods which wrap
>>> cocoa and those added by the bridge (which can use the standard .NET
>>> naming conventions). In addition it allows mobj to automatically
>>> register methods with the objective-c runtime so you don't have to
>>> litter your code with
>>> [ObjectiveCMessage
>>> ("observeValueForKeyPath:ofObject:change:context:")]
>>> like you have to do in Monobj.
>>
>> I appreciate this direction: exposing the full API, and then  
>> providing
>> wrappers, but I am not sure that it is a good idea to expose the
>> low-level API.
>
> Maybe I wasn't clear. I was making two points there:
>
> 1) Using names_like_this allows them to be automatically registered
> with the objective-c runtime so you don't need to force this with an
> attribute as you do in Monobj.
>
> 2) If the Cocoa wrapper methods are_named_like_this and methods added
> by the managed framework are named BeginInvoke then it is crystal
> clear which is which and where people need to look for documentation.

two good points yes.

yours,
marc