[Mono-osx] MonoMac parser.cs

[Michael Bluestein]

categories are similar to extension methods perhaps

On Apr 20, 2010, at 10:59 AM, Duane Wandless <duane at wandless.net> wrote:

> In the particular case of NSArray and NSMutableArray our runtime has  
> been extended to natively convert NSArrays to C# arrays and back so  
> the only code that we bound is the required interop code for NSArray.
>
> That is an interesting strategy and is limiting (I think).  How I  
> use NSMutableArrays is to populate them in C# then send then to the  
> native obj-c UI NSArrayControllers, etc.  I then can manipulate the  
> array in C# and the UI updates as expected.  If the only bindings  
> exposed are to convert from a List to NSArray then this use would  
> not be possible.
>
> Many bits from Foundation make sense for Objective-C programmers as  
> they are dealing with a low-level language and are redundant with C#.
>
> I believe this statement is not true, given how I use NSArrays.  I  
> need to be able to manipulate the underlying object so the UI is  
> automatically updated.
>
> We do not currently support a mapping to categories as they do not  
> really have a counter part in C#.
>
> I may be too simple... but I view a category as nothing but  
> additional methods on the class.  But I may be missing some nuance  
> of a category.
>
> At a minimum I believe the bindings must expose the addObject,  
> insertObject, remove etc selectors on the arrays.
>
> Duane
>
> On Tue, Apr 20, 2010 at 10:03 AM, Miguel de Icaza  
> <miguel at novell.com> wrote:
> Hello Duane,
>
> I have taken parser.cs and extended it to handle categories.  To  
> start I tested parsing NSArray.h.  This produced NSArray.cs and  
> NSMutableArray.cs.  I have "full" bindings for these obj-c classes.
>
> We do not currently support a mapping to categories as they do not  
> really have a counter part in C#.
>
> They are *similar* to interfaces, but they can be interfaces with  
> optional components so there is no direct mapping to them.
>
> For the delegate pattern we settled on classes that have been  
> labeled as "Models" (read more about that on our binding page).
>
> NSMutableArray:  http://monobin.com/__m335d328c
> NSArray:  http://monobin.com/__m36c66b6e
>
> Nice.  For the particular case of Foundation, we have taken an  
> approach to only bind what is actually *required* as opposed to  
> binding everything.   Many bits from Foundation make sense for  
> Objective-C programmers as they are dealing with a low-level  
> language and are redundant with C#.
>
> In the particular case of NSArray and NSMutableArray our runtime has  
> been extended to natively convert NSArrays to C# arrays and back so  
> the only code that we bound is the required interop code for NSArray.
>
> So we suggest to work instead on the AppKit bindings.
>
> However not all the bindings generated are valid.  For example I do  
> not know how to generate a binding for this selector (note I do not  
> use this selector, just an example):
> - (void)sortUsingFunction:(NSInteger (*)(id, id, void *))compare  
> context:(void *)context;
>
> Correct, the parser does the heavy lifting, but requires human  
> intervention to fix the output.
>
> Then comes the question of constructors.  Take these two (the 2nd is  
> not really a constructor I know) from NSMutableArray for example:
> + (id)arrayWithCapacity:(NSUInteger)numItems;
> - (id)initWithCapacity:(NSUInteger)numItems;
>
> My parser exposes these as:
>
>         [Static]
>         [Export ("arrayWithCapacity:")]
>         IntPtr ArrayWithCapacity (uint numItems);
>
>         [Export ("initWithCapacity:")]
>         IntPtr InitWithCapacity (uint numItems);
>
> This is a great question.
>
> Factory methods should be declared as static methods, and we  
> *typically* use the FromXXXX or CreateXXX naming pattern for them,  
> so the above would look like this:
>
> [Static, Export ("arrayWithCapacity:")]
> NSArray CreateArray (int items);
>
> Notice that I took the liberty of changing the uint to int because  
> that makes the method CLS compliant.
>
> In this case it is a debatable change as there could be arrays with  
> more than 2 gig elements, but in many other places in the API this  
> is not the case, uint has been used to get an extra bit that is not  
> required.
>
> So how can we support the extra 2 gigs of elements while still  
> allowing other languages the most common use case?  We keep the  
> signature as it was originally produced, and introduce a new overload:
>
> [Static, Export ("arrayWithCapacity:")]
> NSArray CreateArray (uint items);
>
> And then on a helper class in Foundation/NSArray.cs we would do:
>
> partial class NSArray {
>      static NSArray CreateArray (int items){
>           if (items < 0) throw new ArgumentException ();
>           return CreateArray ((uint) items);
>      }
> }
>
> Now to the second question:
>
> First I do not think returning an IntPtr is correct.  It should  
> return NSMutableArray.  But IntPtr follows what was started with  
> MT.  Returning an IntPtr will require calling GetNSObject which  
> seems cumbersome.  Unless I'm missing something.
>
> In the specific case of *constructors*  the binding generator  
> recognizes the pattern:
>
> IntPtr Constructor (ARGS)
>
> As being the constructor for the class.   This is required because  
> constructors generate different code than regular method bindings.
>
> So you will see in all of our APIs that we expose that pattern, but  
> that this is never translated into an actual exposed IntPtr, it is  
> always translated into the correct method name.
>
> Miguel.
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20100420/3c2b8f10/attachment-0001.html