recursive types work

Havoc Pennington hp at
Wed Dec 29 15:08:20 PST 2004

On Wed, 2004-12-29 at 02:47 -0500, Havoc Pennington wrote:
> DICT as it is in today's D-BUS is just an
> ARRAY of STRUCT { string, variant } with a special-case typecode.
> i.e. :
>  - it is always string,variant not parameterized
>  - the distinction between data structures like 
>    array of pairs vs. binary tree vs. hash table 
>    is irrelevant to D-BUS and only applies to bindings
> I suppose DICT might as well be parameterized, it wouldn't really be
> harder at all for dbus and most languages (perl, python, C++) should be
> OK with it. In fact we could implement DICT exactly like ARRAY, except
> that the type parameter is validated to be a STRUCT with two fields.

Thinking about this further, what about the following:

 - no DICT on the protocol level
 - Introspect() data can have a "treat as dict" flag similar 
   to the way it can have names for structs; this flag 
   would apply to any array of two-field structs
 - bindings could choose to map any array of two-field structs
   into a dict instead of an array of struct, following either
   the introspect flag or application programmer request

The current dict accessor functions in dbus-message.h could easily be
implemented on top of this; simply make them work if you use them to
iterate over an array of two-field structs.

I suppose DICT should have one guarantee that an array of pairs doesn't
have, which is uniqueness of the keys. However, that isn't enforced on
the protocol level right now anyway (and I don't really know how it
could be)

I like this approach a lot, since the DICT implementation on the
marshaling level is just going to be a lot of pretending the thing
labeled dict is really an array and will make a mess. Cleaner to just
leave DICT as syntactic sugar.


More information about the dbus mailing list