[Mono-osx] [ANN] mcocoa 0.7 and mobjc 0.8

[Jesse Jones]

On Jan 11, 2010, at 3:26 PM, Lee V. Andrus wrote:

> 
> 
> Jesse Jones-2 wrote:
>> 
>> 
>> On Jan 8, 2010, at 2:16 PM, Lee V. Andrus wrote:
>>> On another note, I noticed that there are still no wrappers classes or
>>> interfaces for Objective C Protocols, although their methods are wrapped
>>> in
>>> each class that "conforms to" them.  Methods in Category
>>> NSDraggingDestination each have a parameter of type "id
>>> <NSDraggingInfo>". 
>>> Since no class that conforms to that Protocol is exposed in the framework
>>> header files, nothing about it is generated by your generator.  I will
>>> probably need to create my own set of extension methods to handle this.
>> 
>> This has been on my list of things to do, but it's been a rather low
>> priority because I have never come across a use case where I thought it
>> would be useful. If you don't mind my asking, where do you think they
>> would be useful?
>> 
> In calling or overriding methods with parameter(s) of type "id
> <pROTOCOLnAME>", like those of Category NSDraggingDestination.  Handling
> Drag and Drop requires the application to override at least one method of
> that Category and call methods of Protocol NSDraggingInfo.  A wrapper for
> the Protocol would be very helpful.  But since there is no class in the
> framework headers that conforms to it, your generator does not generate even
> any example of what it might look like (although their form is not hard to
> for someone who has peeked at your source code to deduce).

I think the issue here is that there is a mismatch between the dynamic world of Objective-C and the much more static world of C#. If you need to call a method which is not exposed via the static C# classes then you need to use NSObject.Call. If you want to override an Objective-C method then you just define a method that starts with a lower case letter:

internal sealed class MySomething : NSSomeThing
{
	public void concludeDragOperation(NSObject sender)
	{
		...
	}
}

Note that you do not override a C# method (tho sometimes the C# base class will have a method with the same name in which case you'll need to use the new keyword). This should work even with protocols because of the way Objective-C does duck typing.

> 
> Sometimes the application needs to pass an argument that conforms to a
> Protocol to a framework method.  NSPrintPanel's "-
> (void)addAccessoryController: (NSViewController<NSPrintPanelAccessorizing>
> *)accessoryController" is one such method for which there is no example in
> the framework headers of a class conforming to the Protocol. A Mono
> interface for the Protocol may be useful in creating the class that conforms
> to it, although optional methods may complicate creating the class as a
> formal implementation of the interface.

I'm not sure it would be all that useful except perhaps for IDEs like MSVC that have that slick completion for auto-completing overrides (and I presume implementing interfaces).
> 
> This brings up another point.  MCocoa wraps NSDraggingInfo with a class of
> extension methods.  On the face of it, this is a close analogy of a
> Category.  But the application program that uses these methods needs to
> override them rather than call them.  An extension method wrapper is not
> very useful for this.  

Right, but it is rather trivial to just write the methods yourself as I did in the example above.

 -- Jesse