Re: [gtk-list] Re: Gtk and the scripting languages of the world

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.kjahds.com> writes:
>
> On 22 Aug 1997, Marius Vollmer wrote:
> 
> > Then, some objects are passed by reference for efficiency reasons (the
> > transparent GdkColor) and some are passed by reference to hold
> > additional return values (the mask).  These conventions are not
> > enforced thru the type system and are therefore difficult to extract
> > for automatic stub generation.
> 
> This is a severe issue, along with the more subtle one of objects that are
> always described as pointer (like GdkWindow* and GtkObject*). Some of
> these objects are pointers to objects that are stored elsewhere (like
> GdkColor's, for example), and some of them are merely big clumsy
> structures (like GdkEvent, I believe) that are always copied, or at least
> you don't need to worry about retaining the original pointer.

We could give GdkColors and GdkEvents value semantics (as you say
below), just like ints.  They are converted into native interpreter
objects when crossing the boundary.  When the number of these value
types is small, that shouldn't be a problem.  Otherwise, we could
establish a scheme for automatically creating conversion procedures,
just like there will be for functions.
 
> There really needs to be some way to distinuish these types easily (a note
> in the documentation or headers would suffice) and, ideally, provide
> reference counting for all of the former objects, so that any environment
> could safely retain a reference to them. (This wouldn't be very easy for
> GdkColor*'s, though.)

We must make sure that everyone adheres to the value semantics of
these types and never stores a pointer to them.

> [...]
>
> > Gtk should also acquire a dynamic type system.  Most of it is already
> > there, in the form of GtkObjects and GTK_ARG_INT, etc. 
> 
> But GTK_ARG_INT isn't sufficient if the INT is really an ENUM.

We need genuine enums, agreed.
 
> > There will also be some form of automatic memory management that Gtk
> > has to respect.  This mostly effects how Gtk treats values from the
> > interpreter that it stores away (like callbacks, or arbitrary user
> > data) but also for Gtk objects in interpreter land.  Gtk already has a
> > reference counting mechanism.  Although reference counting has its
> > problems, I think we can make it work with some care.  (We only allow
> > cycles for objects that are forcefully destroyed by the user, like
> > widgets.)
> 
> Callbacks are pretty simple (the userdata gpointer is almost always
> sufficient, though I think idle and timeout are missing deletion
> callbacks.)

Do signal handlers have deletion notification?  There are the global
`destroy' and `marshal' functions, but I would prefer to have
individual deletion callbacks for each signal handler I install.

> But a real problem is the raw pointers used for user_data.
> Without a length, these pointers are essentially useles. My Perl module
> can successfully store user data in a Gtk object by storing a second
> argument describing the Perl type of the data, but access to foreign data
> is impossible, unless you want to guess it is a ASCIIZ string.

I think accessing foreign data is not important.  But we could couple
the object_data mechanism with the the type system, so that every
datum also stores a type.