[Gtk-sharp-list] Using IList for API beauty
Gonzalo Paniagua Javier
22 Apr 2003 15:45:18 +0200
El mar, 22 de 04 de 2003 a las 15:36, Lee Mallabone escribió:
> Hi all,
> While documenting various classes in Gtk#, I come across some API bits
> that I'm not too keen on.
> One thing I've seen a few times is things like this constructor from
> public RadioButton (GLib.SList group);
> Now this is completely accurate from a Gtk+ point of view. However, from
> a Gtk# point of view, I think this would be *much* more elegant if its
> public API was actually:
> public RadioButton (IList group);
> Am I dreaming? Is this feasible? I'm not entirely certain if it can be
> done efficiently, or if a class that implements IList would still have
> to be wrapped into a GLib list before passing it down to the C
> I would expect any .NET programmer to know exactly what an IList is
> after very little training, but I'd also expect that most would have to
> go hunting for docs to find out exactly what a GLib.SList does, (and as
> it happens, they wouldn't find any yet).
> Am I alone in thinking IList usage would be nicer? If not, could someone
> point me in the right direction to implement this?
I think that a possible option would be making GLib.SList and GLib.List
implement all those useful interfaces: ICollection, IList,
IEnumerable... And then provide constructors for all of them (the 2
types and the interfaces).
May be it would be nice to add a RadioButton (params Gtk.Button 
buttons) constructor too (and then create the GLib.SList that is passed
to unmanaged code from the array).
-Gonzalo / just my 2c