structs, custom type

[Havoc Pennington]

Hi,

On Thu, 2004-03-11 at 13:47, Olivier Andrieu wrote:
> OK. Actually right now it's quite easy to encode it just like a custom
> (i.e. a name + a length + data) but with a succession of arguments in
> place of a dumb byte array. It will probably be easier to move type
> information at the beginning once this is done also for the whole
> message.

Yeah, the whole message body conceptually becomes a struct once we have
struct support and so we should be able to share the code.

I wouldn't want to apply this patch to just add TUPLE; we should have
only one of STRUCT, CUSTOM, TUPLE, DICT I think. I wouldn't add TUPLE
until we make the global decision and clean up the other stuff.

Guess the one we want is TUPLE as you have it here, but named CUSTOM.
i.e. a type with a name label and then a tuple of typed elements.

The argument for DICT mostly hinges on the ability to have variable-type
values in it. Perhaps this is an argument to have a DBUS_TYPE_ANY
typecode so you can have "struct of string, any" and then an array of
those is a dict.

TYPE_ANY doesn't make sense unless you can have a type spec separate
from the value, but we can already have a type spec separate from value
in the form of ARRAY (where the values don't have their own typecode). 
ANY basically means a value with a typecode in front of it. So I guess
ANY is required.

> It also fixes a bug in _dbus_marshal_get_arg_end_pos for custom types
> (it passed the test because the custom value happened to be the last
> one in the message !).

Be sure to mention this fix separately in ChangeLog.

Quick comments on the patch:

 - the convention should be name_p, name rather than name, _name
 - it would be good if the unit test tested recursive TUPLE
   (TUPLE with a TUPLE member with an ARRAY member ... type of stuff)
 - the spec also needs to be updated

Havoc