[Mono-osx] mobj discussion

[Jesse Jones]

On May 19, 2009, at 10:48 AM, Miguel de Icaza wrote:

> Hello,
>
>   [ I changed the subject line to make it easier to spot the threads ]
>
>> * 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.
>
> In MonObjc it seems that the source is that this is auto-generated  
> code,
> is the code also autogenerated in mcocoa?

There's a little bit of hand-written code in mcocoa for stuff  
like .NET-style enumeration support in the collections or BeginInvoke  
in NSApplication, but pretty much all of it is autogenerated.
>
>
> It seems to me that these APIs need to be thought out in terms of what
> they do and expose the proper name and pattern, something that follows
> the Framework Design Guidelines.
>
> 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.
>
>
>> 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.

   -- Jesse