Object serialization

[Luigi Paioro]

I rather use a dictionary instead of list (struct), because a signature 
like '(siiay)' imposes a well defined "attributes order", which could be 
a bit constraining.

Anyway, suppose you have for instance (speaking in Java terms):

package org.mapping.example

class Foo {

   String name;
   int width;
   int height;
   byte[] colours;
   Bar bar;
   FooBar foobar;

   public Foo()...
   ...
}

class Bar {
   public String name;
   ...
}

interface FooBar {
   public int id;
   ...
}

package org.mapping.example.myimpl

class MyFooBar implements FooBar {
   public int id;
   public boolean flag;
  ...
}

class YourFooBar implements FooBar {
   public int id;
   public String surname;
  ...
}

This is a rather complicated example, because there are nested classes
and one of them (foobar) can be of two distinct types with different
attributes.

I agree with Simon that the target should be to define the _semantic_ of
the dictionary entries. A dictionary composed with such a specific
semantic could be recognized and mapped into an object (for OO
languages) or whatever else (for other languages) or just let it as a
dictionary (which you know has a special meaning).

So, for instance, this could be an example of mapping (pseudo-python 
example):


{"class_name": "Foo",
  "class_namespace": "org.mapping.example",
  "name": "My foolish Foo name",
  "width": 50,
  "height": 250,
  "colours": (255, 150, 25),
  "bar": {"class_name": "Bar",
          "class_namespace": "org.mapping.example",
          "name": "My foolish Bar name",
          ...
         },
   "foobar": {"class_name": "MyFooBar",
              "class_namespace": "org.mapping.example.myimpl",
              "id": 125300,
              "flag": true,
              ...
             }
}


any method to which one wishes to pass Foo should declare a signature 
very general like 'a{sv}'. If this array of dictionary entries contains 
two keys named "class_name" and "class_namespace", then it defines a 
complex structure that (in principle, if the language allows) can be 
unmarshaled as an object instance (for which you must have the class 
coded in such language, otherwise it remains a dictionary). And this 
process is iterative. The meaning of "class_name" and "class_namespace" 
I think is intuitive.

Perhaps a more strongly typed signature is better, but for the time 
being I don't find a better solution...

Whether to include this marshal/unmarshal mechanism into the dbus 
bindings or not... well, I don't know... it depends on the bindings 
developer choice...


Thank you very much for your comments.

Luigi


Matthew Johnson ha scritto:
> My opinion is that you should serialize it to the native types
> corresponding to the contents of that object. So, if you have a class:
> 
> class Foo 
> {
>    String name;
>    int width;
>    int height;
>    byte[] colours;
> 
>    public Foo()...
>       ...
> }
> 
> then any method to which you wish to pass Foo, would declare either the
> signature 'siiay', or the signature '(siiay)' (I'm not bothered which).
> 
> Bindings should then provide support for making this easy. This is the
> approach which Java DBus takes. This makes it easy for a client written
> in a different language, possibly one without well-defined objects, to
> interface to your code from just the introspection data. I don't see
> that this requires any special support or greed conventions.
> 
> Of course, if you're talking about something else, then do say so (-:
> 
> Matt
>