On Monday, 18 February 2013 at 01:27:17 UTC, Steven Schveighoffer
wrote:
On Sun, 17 Feb 2013 19:58:06 -0500, Nick Sabalausky
<[email protected]> wrote:
On Sun, 17 Feb 2013 13:18:05 -0800
Walter Bright <[email protected]> wrote:
On 2/17/2013 12:51 PM, Jacob Carlborg wrote:
> I just stripped out all D1 and Tango related code from
> Orange.
> D1/Tango is still supported in the d1 branch. Hopefully
> this will
> make it easier to integrate into Phobos.
>
> It also now supports UDA's for indicating a
> field/class/struct
> shouldn't be serialized:
>
> class Foo
> {
> @nonSerialized int a;
> }
>
> @nonSerialized class Bar { }
Hmm, shouldn't it be the other way around - marking the ones
to be
serialized?
You're already opting-in to serialization anyway when you say
"serialize object foobar". @serializable would just be
redundant.
I think Walter's point is that the author of foobar may not
have opted in.
My response to that is, so? If someone is trying to serialize
your class, and you didn't test for that, too bad for that
person if it doesn't work.
The reality is, an author may write foobar without intending it
to be serializable, but it actually is. In that case, it is
still on the user, but if it works, great! The user is taking
the risk that later the serialization breaks, and could always
submit a patch to the author of foobar if it somehow becomes
not-working in a future version.
To have to say:
struct S
{
int x;
int y;
}
is serializable seems like super-redundant info. The D type
system is one of the most advanced I've ever seen. Let's try
and use it!
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)?
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.
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 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.
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.
