[Gtk-sharp-list] Replacing/Enumerating IList usage
Miguel de Icaza
10 May 2003 16:57:08 -0400
> 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.
> 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.