16 Aug 2002 11:28:30 -0500
On Fri, 2002-08-16 at 10:11, Paolo Molaro wrote:
> I reply to this mail just because it brings up one issue I'm worried
> about in the Gtk# API.
> I think GList and GSList should not be exposed in the public Gtk# API.
> They are ugly as hell and should be only used to interface to the
> library: the types exposed should be plain arrays or ArrayLists.
If you look at glib/SList.cs, it is currently a subclass of ArrayList,
although it will most likely just be an implementor of IList in the end.
Taking this approach allows us to put all the marshaling logic inside
the type itself instead of having to generate a lot of ugly code all
through the binding to accomplish the marshaling from an ArrayList. As
long as the type exposes the IList interface, I don't see what your
issue is. It can be used just like an ArrayList. It's a hand wrapped
class, so we're certainly not going to expose the underlying internal
> The same goes for other internal details of the Gtk+ C API, like, the
> use of IntPtr.Zero should be never required to write a Gtk# program, it
> just doesn't belong to a C# interface. Also, eliminating it will give
> us some chance of using Gtk# in untrusted code.
This is mostly a non issue already. Null handling has been added that
maps null parameters to IntPtr.Zero for marshaling. As new parameters
are discovered, we are marking them null-ok in the XML.
> Uhm, didn't I say I had one issue?
> Well, I have also a third: C# won't be the only language to use the
> binding to Gtk. I would be nice to have the binding be a thin wrapper of
> the C API and have Gtk# on top of that to provide the C#-way of doing
> things, while other languages will be able to reuse the binding to
> implement the interface to their language as best as it suits _that_
I don't know if this is a signal handling troll, or what exactly your
point here is. :) There is nothing C# specific that we are doing. We
are generating a set of IL classes that correspond to the paradigms set
forth in the BCL. It is up to the language implementor to interact with
these classes in a manner stylistically correct for that language.
Mike Kestner <email@example.com>