structs, custom type
Thu Mar 11 21:27:15 PST 2004
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
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
More information about the dbus