Orange - Free from D1/Tango

Jacob Carlborg doob at me.com
Mon Feb 18 23:50:04 PST 2013


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


More information about the Digitalmars-d mailing list