On 2010-06-20 00:34, Michel Fortin wrote:
On 2010-06-19 15:52:51 -0400, Jacob Carlborg <d...@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
