18-Feb-2013 05:27, Steven Schveighoffer пишет:
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!

Exactly.

Would be nice to be able to mark the whole structs as non-serializable though. And of course, to not have to import serialization library just to get the annotations.

-Steve


--
Dmitry Olshansky

Reply via email to