On Sat, 2004-11-06 at 10:53 -0500, muppet wrote: > On Nov 6, 2004, at 9:12 AM, Owen Taylor wrote: > > > On Sat, 2004-11-06 at 08:34 -0500, muppet wrote: > >> answer this, then: how will this introspection info help to bind > >> GBoxed types (generic structures) > > > > If they are simple structures like GdkRectangle, that's reasonable to > > include within > > did you trail off here or mean "include within G_TYPE_POINTER > properties"? "include within the introspection framework. I was taking a guess that your problem with boxed types wasn't with opaque objects with copy/free/accessors but rather with things like GdkRectangle that are simple data structures. We could include information about the members of such structures in the framework. Or we could just go ahead and add gdk_rectangle_get_width(), etc. > the problem here is that the boxed types will require either a full > description of their members' types and offsets in typelib, or > hand-written glue to access the members. for example, in gtk2-perl, > some structures get automatically turned into native perl data > structures (a hash or array), and this marshaling requires hand-written > glue for each type; even if you don't do this, we have to hand-code (or > custom-generate) accessors for each struct member. Computing member structure alignment isn't that hard; libffi has it, ORBit has it, etc. > >> G_TYPE_POINTER object properties, > > > > Shouldn't be any in properly bindable APIS. > > "shouldn't" is the key; there are several. in fact, some signals with > proper argument types still require custom marshalers to get the > semantics correct (write-through parameters, etc). > > in gtk+ itself, there are several signals with G_TYPE_POINTER > properties: > > GtkEditable::insert_text Horrid legacy interface, but it's an int *, so yes, a real example. In/out parameter. > GtkMenuItem::toggle_size_request Another int *. Output parameter. > GtkNotebook::switch_page That argument is just a dummy for backwards API compat. It isn't meaningful in C either. > GtkPathBar::path-clicked (not public, is it?) Not public. > GtkSpinButton::input A double *. Output parameter. > GtkTreeModel::rows_reordered Another int * (this one is an array, not an in/out or output parameter) this one is probably not introspectable, because the length of the array is implicit in the interface :-( So, 4/303. Not bad. :-) > >> variadic C functions, > > > > These are only convenience functionality in properly bindable APIs. The > > language binding might need similar convenience glue that is hand- > > written. > > in other words, you don't think that Maciej's goal of zero hand-written > code in bindings (even for well-behaved APIs) is possible? Depends. The binding will be 100% functional without the hand glue. But > i think it will suffer at the hands of the 90-10 rule; it will be quite > easy to get 90% of the bindings done right and automatic, but that last > 10%, mostly esoteric but some critical things, will be an albatross. The goals of this effort as I see them are: - Allow people to write fully introspectable objects (for the D-BUS bindings, for scriptable apps interfaces, etc.) - Standardize all the .defs, head scanning, etc, stuff that is being done currently in different language bindings. I don't really see a 90/10% problem with either. The 90% will beuseful. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part