[Gtk-sharp-list] Replacing/Enumerating IList usage

[Miguel de Icaza]

Hello Lee,

> First, I'm afraid this post is a little long, but I'm hoping it will act
> as a motivator for some further discussion on what, if anything, to do
> about list usage in Gtk#.

Thanks for putting together this list.

> To consider a solution, I think it possibly helps to think of functions
> that *return* lists separately from functions that accept lists.

I agree.

> Many or all of the functions that *return* GLib lists could be converted
> into returning ILists by hacking GLib.ListBase to implement IList
> instead of just ICollection. 
> 
> Alternatively, with some .custom writing, we could change the current
> list return types into their relevant specific array types. Eg. instead
> of returning a GLib.List for a 'Widgets' property, just return Widget[].
> When the programmer doesn't want/need to modify the return type, I
> personally favour the latter approach, as it's easier to see what the
> API is doing just by glancing at the method signature.

I like this approach a lot more too.

> Methods that take GLib lists as arguments might be much more difficult
> to marshal into something that the C API is happy to accept... I think
> accepting an "IList" as the argument is probably making more effort than
> it's worth. Again, I think it might be good to accept an array of a
> specific type, which is then internally converted to a GLib.(S)List
> before being passed to the underlying C function. 

I would vote for this as well.

The reason is that typical code does not deal with Glib.SLists/Lists,
but something else.  Every piece of code that deals with these APIs
basically has to "wrap" its internal data structure before invoking the
API.  I vote for putting the burden on Gtk# instead of the programmer.

> Any opinions on what I've suggested? My brain is a little fried right
> now, but I suspect I could start write simple custom methods that
> replace the methods/properties that currently return Glib lists with
> array types.
> Does anyone have a different approach that might be more appropriate?

I think that .custom files are the way to go here.

Thanks again for this detailed audit of the API.

Miguel