[Gtk-sharp-list] LibGlade

[Paolo Molaro]

On 08/13/02 Rachel Hestilow wrote:
> The problem is that the "data" member is stored as a gpointer. I suspect
> what we will have to do is give up on any hope of guaranteed typesafety
> from that and just add a variety of casting-operator accessors for the
> common data types. GObject data are easy enough to handle now that
> introspection has hit CVS, but struct pointers will _never_ work (no way
> for the list class to "sniff" the struct type), so the user will have to
> use the StructName.New(IntPtr) construct.
> 
> If the lists are mutable, the marshalling situation becomes a lot
> trickier because of the necessity of generating IntPtrs. Sometimes this
> can be done with an IntPtr constructor, or unsafe code, but this is not
> always possible with managed types.

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.
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.

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_
language.

Ok, I'm done, flame away.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better