Why return MessagePackObject instead of simple System.Object?

[itaign]

Hi,

In our scenario we have a class which contains a Dictionary<int, object> and List<Dictionary<int, object>> members.

The de-serialization process provides us MessagePackObject instead of System.Object even though the serialization resulted bytes have all the required information to infer the type of each object (we use value types for all our simple objects).

Is there a way to avoid using the MessagePackObject and return simple System.Object as the de-serialization result?

Thanks, Itai

[yfakariya]

Mark your dictionary typed property with [MessagePackRuntimeCollectionItemType] attribute. It specifies that you want to embed CLR type information in serialized objects, so the serializer will be able to know original objects' types, that is, dictionary values will have their original objects instead of MessagePackObject. As you can see in wiki, note that it loses interoperability towards other implementations which don't know about embedded type information.

[babaq]

Hi, I just tried to add attribute to my property, and it works just fine, but it doesn't work for nested ones.

public class my
{
    [MessagePackRuntimeCollectionItemType]
    public Dictionary<string,object> envparam; // works

    [MessagePackRuntimeCollectionItemType]
    public Dictionary<string,List<object>> cond; // doesn't work
}

is there a way to make both cases work, or msgpack just don't support it yet?

i am also wandering if an object in Dictionary<string,object> itself is a List<object>, will MsgPack embed CLR type info, and do proper converting when deserialized?

Seems to me that runtime polymofism should make all object runtime types recursively inferred and converted in serialize/deserialize process.