Questions ad marshalling multi-dimensional arrays

[rony]

Hi Simon,

thank you *very* much for your quick answers!


On 23.06.2011 13:59, Simon McVittie wrote:
> On Thu, 23 Jun 2011 at 12:13:48 +0200, rony wrote:
>   
... cut ...

>>           o Which would be the marshalling sequence
>>     
> You can choose whether to use "row-major" or "column-major" ordering.
> Whichever you do, document it as part of your API specification, preferably
> with an example.
>   
Hmm, so there is no pre-determined ordering, independent of language or
programming style when using multidimensional arrays?

Was wondering in what sequences I should expect something like "aai" or
"aaa(su{so})" got marshalled, such that unmarshalling would create an
array with the same ordering as the sender. (Trying to come up with a
binding that handles generically all possible valid array related
signatures, single-dimensioned or multi-dimensioned to any dimension.)

As long as it is really o.k. to do it either way ("arbitrarily"), that's
fine. In this case the user of the APIs and the bindings will have to
research whether the ordering of the multi dimensional array elements
matches the sender's ordering, which I need to prominently document for
my binding's users.


>>           o Given the above example, would it be o.k. to leave out
>>             "trailing empty elements of the array"?
>>     
> You can define it to be OK. If you do, document it as part of your API specification, preferably with an example.
>   
As I am trying to create a binding for a scripting language, I have no
information whatsoever what an application would envision, document.
Therefore the need to know whether it would be o.k. to leave out
trailing empty elements when marshalling an array (no matter what
dimensionality it has).

>>           o Is it possible to marshall an empty array by merely using a
>>             sequence of open_container(DBUS_TYPE_ARRAY) - no-content -
>>             close_container?
>>     
> Yes. Open the container and immediately close it.
>   
Great!


>> P.S.: Are there perhaps any thoughts about defining an explicit
>> NULL/.nil value (maybe at least transportable in the context of variants) ?
>>     
> This is more difficult than it looks because it's an incompatible change to
> the type system.
>
> In the proposed "maybe" type, mX means "maybe X" for any type X; it can
> either have value Just V (where V is any valid value for X),
> or Nothing (analogous to NULL). It's implemented as an array whose length is
> at most 1. See <https://bugs.freedesktop.org/show_bug.cgi?id=27857>. GVariant
> (a superset of the D-Bus type system) implements this, but D-Bus doesn't.
>   
Thank you very much for your explanations and especially this pointer !

Again, many thanks for your help !

---rony