[PATCH] Add a parameterised gtype for structs

[Robert McQueen]

I committed the dbus_g_struct stuff with this tweak yesterday.

Regards,
Rob

Rob Taylor wrote:
> This patch looks good to me. That the glib tests pass without this is
> slightly worrying :/
> 
> Thanks,
> Rob Taylor
> 
> Ole André Vadla Ravnås wrote:
> 
>>Hi,
>>
>>Here's a quick fix for a bug introduced in dbus-binding-tool by the
>>struct patch. Basically the argument list for generated calls to
>>dbus_g_type_get_struct ("GValueArray", ...) wasn't terminated.
>>
>>Regards,
>>Ole André
>>
>>
>>On 2/7/06, Rob Taylor <robtaylor at floopily.org> wrote:
>>
>>
>>>[mm, forgot to reply to list.. damn mornings... ]
>>>
>>>Havoc Pennington wrote:
>>>
>>>
>>>>Ideally we could find a way to use the code in
>>>>dbus-marshal-recursive-util.c to also test the glib stuff. It exports a
>>>>function already (grep for generate_bodies) that returns all its test
>>>>cases as raw data; if we could use that (or export some slightly
>>>>different function) then the glib test suite could just get each test
>>>>case, round-trip it through the glib bindings, and see if it gets back
>>>>the same bytes as the original test case. Really this would be a pretty
>>>>airtight way to test any binding.
>>>
>>>That's a very good idea, I think one thing we discussed with splitting
>>>out the bindings was a unified way to unit test each binding, this seems
>>>a good way of going about it.
>>>
>>>
>>>
>>>>On the bigger picture of the patch - I think we had a discussion about
>>>>how to do structs a while back? Any writeup of why this patch does it in
>>>>this way vs. others, general notes on the approach, etc.?
>>>
>>>Well, as I saw it, there were two options for actually making the
>>>bindings capable of marshalling every signature:
>>>1) produce a true bijection from the glib type system to the dbus type
>>>system
>>>or
>>>2) modify all marshalling recursion to also simultaneously descend the
>>>dbus signature and marshal according to the signature.
>>>
>>>Now obviously the python and perl bindings use 2), as its more natural
>>>for those languages to say how something should appear on the wire than
>>>force users to do odd things to be strictly typed.
>>>
>>>However for glib, strict typing is completely natural, so 1) is the more
>>>obvious choice. 2) would also have meant that several interfaces would
>>>have to have changed (g_proxy_call, g_proxy_add_signal, etc), and that
>>>we'd also have to store property and signal type information in
>>>DBusGObjectInfo. TBH, it just seemed alien to the current modus operandi ;)
>>>
>>>Another option that I quickly discarded due to its foul nature ;) was to
>>>modify all of the dbus-gsignature code so that it could also follow data
>>>as well as the type in order to discover signature for structs as they
>>>existed before this patch, but not only is this horrible, as I'm sure
>>>you'll agree, it also doesn't help for the cases where, say an array is
>>>empty.
>>>
>>>
>>>
>>>
>>>>Also, I asked Colin if he would take a high-level look at it.
>>>
>>>That would be brilliant - it was slightly scary doing this without his
>>>input! ;)
>>>
>>>
>>>Thanks,
>>>Rob Taylor
>>>
>>>_______________________________________________
>>>dbus mailing list
>>>dbus at lists.freedesktop.org
>>>http://lists.freedesktop.org/mailman/listinfo/dbus
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>--- dbus/glib/dbus-binding-tool-glib.c-orig	2006-02-09 00:31:45.000000000 +0100
>>>+++ dbus/glib/dbus-binding-tool-glib.c	2006-02-09 00:33:04.000000000 +0100
>>>@@ -1072,7 +1072,7 @@
>>>          g_string_append_printf (string, ", %s", value_lookup);
>>>          g_free (value_lookup);
>>>        }
>>>-      g_string_append (string, ")");
>>>+      g_string_append (string, ", G_TYPE_INVALID)");
>>>      return g_string_free (string, FALSE);
>>>    }
>>> 
>>>
> 
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus