On Mon, 18 Feb 2013 18:43:16 -0500, qznc <[email protected]> wrote:
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)?
Most likely a mutex is a core library feature, and we can mark it as not
serializeable. If (when?) phobos gets serialization, I would expect the
core types to be marked as such.
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.
For D, we have shared which indicates it may be viewed by more than one
thread. Shared data could be opt-in for 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 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.
I would expect that something that complex has to be specifically written
to deal with serialization.
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.
Just because someone is stupid and tries to serialize a non-serializable
construct such as a gui toolkit, it's not the serializer's fault.
I don't think opt-in is stupid, it's just a more conservative set of
rules. I think the number of constructs that WON'T be serializable will
be far less than the ones that will be.
And multi-thread access items could be made opt-in. I'm not sure what
Orange does now.
-Steve
