Hello Duane,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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 &quot;full&quot; bindings for these obj-c classes.  <br></blockquote><div><br></div><div>We do not currently support a mapping to categories as they do not really have a counter part in C#.</div>
<div><br></div><div>They are *similar* to interfaces, but they can be interfaces with optional components so there is no direct mapping to them.</div><div><br></div><div>For the delegate pattern we settled on classes that have been labeled as &quot;Models&quot; (read more about that on our binding page).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">NSMutableArray:  <a href="http://monobin.com/__m335d328c" target="_blank">http://monobin.com/__m335d328c</a><br>
NSArray:  <a href="http://monobin.com/__m36c66b6e" target="_blank">http://monobin.com/__m36c66b6e</a></blockquote><div><br></div><div>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#.</div>
<div><br></div><div>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.</div>
<div><br></div><div>So we suggest to work instead on the AppKit bindings.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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):<br>
- (void)sortUsingFunction:(NSInteger (*)(id, id, void *))compare 
context:(void *)context;<br></blockquote><div><br></div><div>Correct, the parser does the heavy lifting, but requires human intervention to fix the output.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>Then comes the question of 
constructors.  Take these two (the 2nd is not really a constructor I know) from NSMutableArray for example:<br>+ 
(id)arrayWithCapacity:(NSUInteger)numItems;<br>
- (id)initWithCapacity:(NSUInteger)numItems;<br><br>My parser 
exposes these as:<br><br>   
     [Static]<br>        [Export (&quot;arrayWithCapacity:&quot;)]<br>        
IntPtr ArrayWithCapacity (uint numItems);<br>
<br>        [Export (&quot;initWithCapacity:&quot;)]<br>        IntPtr 
InitWithCapacity (uint numItems);<br></blockquote><div><br></div><div>This is a great question.</div><div><br></div><div>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:</div>
<div><br></div><div>[Static, Export (&quot;arrayWithCapacity:&quot;)]</div><div>NSArray CreateArray (int items);</div><div><br></div><div>Notice that I took the liberty of changing the uint to int because that makes the method CLS compliant.   </div>
<div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>[Static, Export (&quot;arrayWithCapacity:&quot;)]</div><div><div>NSArray CreateArray (uint items);</div><div><br></div></div><div>And then on a helper class in Foundation/NSArray.cs we would do:</div><div>
<br></div><div>partial class NSArray { </div><div>     static NSArray CreateArray (int items){</div><div>          if (items &lt; 0) throw new ArgumentException ();</div><div>          return CreateArray ((uint) items);</div>
<div>     }</div><div>}</div><div><br></div><div>Now to the second question:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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&#39;m missing 
something.<br></blockquote><div><br></div><div>In the specific case of *constructors*  the binding generator recognizes the pattern:</div><div><br></div><div>IntPtr Constructor (ARGS)</div><div><br></div><div>As being the constructor for the class.   This is required because constructors generate different code than regular method bindings.</div>
<div><br></div><div>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.</div><div><br></div>
<div>Miguel.</div></div>