[patch] initial conversion of glib bindings to use signatures

[Colin Walters]

On Fri, 2005-02-25 at 21:33 -0500, Havoc Pennington wrote:
>On Fri, 2005-02-25 at 15:49 -0500, Colin Walters wrote:
>> 
>> Yeah, although GLib programmers are used to the type-unsafety of
>> GHashTable anyways.
>> 
>
>The suckage here is that they are used to creating the type unsafety
>themselves... there aren't APIs that return hash tables really.

True.

>Had a long discussion with Owen where he made some convincing arguments
>for the last one (convert to C struct).
>
>Some ideas in this area:
>
> - we don't necessarily have to generate a struct at all, though we can.
>We can just 
>   declare that "(ii)" can be stored in anything that is:
>   struct { dbus_int32_t field1; dbus_int32_t field2; }
>   so while dbus-binding-tool will probably know how to generate such a
>struct 
>   decl, you can also just declare your own struct if not using dbus-
>binding-tool.

So we could generate glue like this client-side:

#ifndef DBUS_DEFINED_STRUCT_ii
#define DBUS_DEFINED_STRUCT_ii
typedef struct { dbus_int32_t field1; dbus_int32_t field2; } DBusStructure_ii;
#endif

gboolean
org_freedesktop_NetworkManager_frobnicate (int x, DBusStructure_ii *foo, GError **error)
{
  /* invoke dbus method */
}

And we'd have similar typedef bits in the server-side glue.

Is that about right?

> - an arbitrarily complex recursive type can be stored in a single
>malloc 
>   block, so we can ignore the "destructor" problem. Arrays and strings
>   just follow the struct that points to them in the block.

I see, so you can just always use g_free.  That would be nice.
>  
>   Exception: if dicts are GHashTable this breaks, I guess.

It would be a lot less pleasant if they weren't, I think.  Hmm.  I
wonder if we could do some trick using GHashTable internals to lay
everything out in the big malloc block.  Would certainly break if
GHashTable internals broke, but maybe we can get guarantees from glib
people that they won't change, or add API to support this use case, like

GHashTable * g_hash_table_init_fixed (gpointer mem, size_t max_entries); 

> - all interesting architectures use the same alignment for struct
>fields, 
>   but may not use the same alignment for structs (dbus aligns all
>structs
>   on 8-boundary regardless of field types)

Ah.  So we can write generic code to access the structures without being
architecture-dependent.  Cool.

> - I wonder if the convert-to-struct code should be in dbus-message.h 
>   rather than in the glib bindings. Basically just add a 
>   dbus_message_iter_get_as_c_struct () which could be called for any
>iterator
>   and would return the entire complex type starting at the current 
>   iter position. We could even allow using it for the entire 
>   message. So a message with "int, string, int" could be converted
>   to struct { dbus_int32_t; char*; dbus_int32_t; }

That makes sense to me.

>> Have you had a chance to look at the patch, by the way?
>
>Ah, I guess I didn't notice there was a patch. Your mail is confusing in
>evo because the attachment icon always appears for the gpg key...

Yeah, it's annoying evo does that.  Anyways, the patch is committed now,
thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050228/ab0f6a07/attachment.pgp