Re: .defs Issues From Java-Gnome
- From: Havoc Pennington <hp redhat com>
- To: Oskar Liljeblad <osk hem passagen se>
- Cc: gtk-devel-list gnome org
- Subject: Re: .defs Issues From Java-Gnome
- Date: 14 Dec 2000 11:24:10 -0500
Oskar Liljeblad <osk hem passagen se> writes:
> It seems to me that there's much confusion around the "boxed" concept.
> Someone said boxed was a structure with "copy" and "free" methods.
> Looking at the gtk sources there's _ref and _unref for many boxed types.
> (To me, copy is more like "deep clone" rather than ref, and free
> more like "delete" than unref. But maybe they are the same thing?)
Agree, I don't think copy/free and ref/unref are that comparable.
For Inti, there are only a couple types of objects from a
language-binding point of view:
a) value objects that can be cheaply copied; these are passed around
by value and their identity is irrelevant, so I can just create
a wrapper on-the-fly
b) refcounted objects; these have to have a place for object data
and destroy notify, so I can associate the wrapper with the
object and always use the same wrapper with the same object
A surprising case of a) is:
- immutable objects (e.g. GdkVisual) - these can pretend to
be value objects without actually having a copy operation, because
you can make them "copy on write" (there are no methods that mutate
the object, so you never write, so you never copy)
What this means is, for ease of binding, all objects should be either:
- cheaply copiable by value, with no interesting identity
- refcounted with object data and destroy notify (i.e. GObject)
For cheap value objects, including primitive C types such as "int" and
higher-level types such as GtkTextIter and GdkRectangle, sometimes the
object is an out or inout parameter; in those cases you have to pass
the object in to a method by reference, so you can't just copy these
things always.
GLib/Pango/GTK also have a number of objects that just have to be
special cased by LB because they are low-level and scary for C
efficiency reasons.
> But a boxed is also a named structure, with a unique GType value.
> This attributes is important to language bindings because it
> allows signal/function arguments to be specified in more detail.
> (I.e. GTK_TYPE_REQUISITION instead of G_TYPE_POINER/G_TYPE_BOXED.)
>
> Anyway, about "copy" and "free" for a boxed type. What point is
> there in providing them? Most language bindings cannot make use
> of them. I think this is true for garbage collecting/reference
> counting languages, including perl and java (and python?).
I think you would use them for a deep copy, e.g. python has a copy()
function IIRC, which would presumably call copy. But not ref/unref; an
object with ref/unref is not copiable in this sense.
> Why? Because the language need to be informed by gtk when the boxed
> obj is deleted. A delete_notify, in other words. It is either
> this or a pointer slot for a foreign reference.
In my experience you only need a delete notify for the refcounted
objects where you want to maintain a 1-1 mapping between wrapper and
wrapped object, to preserve object identity.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]