structs, custom type

[Olivier Andrieu]

 Havoc Pennington [Thursday 11 March 2004] :
 >
 > 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.

yep, that's the idea.

 > 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.

I still see an interest in CUSTOM as it is now : an amorphous byte
stream without any DBus type information (except the name). It's
almost the same as a STRUCT with a single element of type `string' or
`byte array' except that the mapping of byte array or string may not
be the best type to represent binary data in the target language. 

Btw, can DBus strings contain nul bytes ? The spec does not seem to
specify this. If not, then that means you'll have to use a `byte
array' typecode to transmit binary serialized python data (for
instance). But then the python bindings may choose to map this to a
list of ints or a list of characters whereas python unserialization
expects the data to be in a string.

As for STRUCT and TUPLE, the difference I see is one would be named
and the other not, so yes I guess only one of those two should exist. 

 > 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.

I'm not sure. ANY can seriously undermine the idea of a type
signature: in a pathological case, the type signature could contain
only anys, leaving the actual typecodes in the body. So perhaps ANY
should only be allowed in some contexts (within an array). Sounds
complicated. 

Are DICTs really necessary ? couldn't they be subsumed by STRUCTS ?

-- 
   Olivier