Review: std.msgpack

[Jacob Carlborg]

On 2010-06-20 00:34, Michel Fortin wrote:
> On 2010-06-19 15:52:51 -0400, Jacob Carlborg <doob at me.com> said:
>
>> Orange (http://dsource.org/projects/orange/) doesn't have those
>> problems (it probably has other problems). These are some of the
>> features:
>>
>> * It automatically serializes the base classes
>> ...
>> * Serializes through base class references
>> * Serializes third party types
>
> By that, do you mean it serializes the fields of the base classes and
> other types even when those types weren't designed to be serialized?
> Personally, I think it's dangerous to break encapsulation like that. You
> can never guaranty that the base class won't contain data that shouldn't
> be serialized (a reference count, a file or socket handle, cached data
> bound to be different at a later time, a reference to the root of a huge
> hierarchy isn't "part" of the object, etc.). Serialization might work
> for one version of the base class, and when the implementation changes
> it breaks.

You always have the option to register a serializer for a specific type 
if you want to customize the serialization. I'm also thinking of adding 
the option to register a serializer for a specific field in a specific 
type.

> I prefer the reverse design: only types with a known serialization
> procedure are serializable. That said, I can still appreciate the merit
> of simplicity when it comes to serializing types like this one:
>
> struct Point { float x, y; }
>
> But it's easy to make it explicitly serializable too:
>
> mixin AllMembersArchivable!(Point);

In Orange you have three options:

1. Let the library do all the work
2. Implement two methods in the class/struct that handle the serialization
3. Register a (de)serializer function/delegate that handles the 
serialization

You can also combine these three options. For example, let the library 
handle two out of three classes in a class hierarchy (1) and handle the 
third one by yourself (2 or 3). The third option also allows you to 
customize third party types.


>> * It's licensed under the Boost license
>
> And mine isn't public yet. :-)
>
>> The only thing missing that I want to implement is to somehow support
>> different versions of classes and structs. I'm currently working on
>> porting the XML archive to Phobos.
>
> Versioning is something I generally prefer to handle at the application
> level. Having class and struct fields serialized with a string key makes
> that quite simple and allows keeping the serialized data compatible with
> earlier versions of the same struct/class.

Every value in Orange is serialized with a key. By default an object 
will just have a numerical id from a counter and the fields will have 
their names as the key.

-- 
/Jacob Carlborg