On 2013-02-19 00:43, qznc wrote:

I agree that for lots of code it is redundant (data structures in
general). It might even be desirable for library code, whose author did
not consider Orange. However, it might lead into subtle bugs in some cases.

For example, what happens with a mutex? Would Orange serialize it with
all its state (locked or unlocked)?

It would just serialize it. It serialize all internal sate, except for void pointers.

What happens with data structures, which are used in parallel. For a
consistent serialization it might be necessary to take a lock first. In
this case, the data structure must be able to provide its own
serialization method.

Yes, or perhaps the user can use a lock or similar when perform the serialization?

I have not seen a "skip on serialize, but re-initialize on deserialize"
annotation, which would be the correct behavior for uncontested
thread-safe data structures using locks.

The library supports custom serialization, both for your own types and for third party types.

https://github.com/jacob-carlborg/orange/blob/master/tests/Custom.d
https://github.com/jacob-carlborg/orange/blob/master/tests/NonIntrusive.d

The most complex case would probably be something like a GUI toolkit. If
I serialize a GtkD app on Linux and deserialize it on Windows, will it
be able to produce a working GUI? It must provide a custom deserialize
method to do that.

Yes, it will most likely need a custom (de)serialization method. If we take DWT as an example. It could automatically serialize all internal state except for the native widget that is stored. So in this case it would probably be best to use custom serialization and only use the public API to set the properties. This would make sure that the underlying native widget is updated as well.

Theoretically it would be possible to serialize the native widget as well, at least on Mac OS X. That's how Xcode/InterfaceBuilder is working.

Looking at all those edge cases, an opt-in approach seems not that
stupid to me. It might be tedious to add all those @serializeable
annotations, but at least you do not run into weird deadlocks.

I don't agree. I think that most data types _can_ be serialized.

--
/Jacob Carlborg

Reply via email to