Review: std.msgpack

[Michel Fortin]

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.

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);


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

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/