[Mono-osx] mobj discussion

Miguel de Icaza miguel at novell.com
Tue May 19 13:48:21 EDT 2009


   [ 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.
In MonObjc it seems that the source is that this is auto-generated code,
is the code also autogenerated in mcocoa?

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

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


More information about the Mono-osx mailing list