Orange - Free from D1/Tango

[Dmitry Olshansky]

18-Feb-2013 05:27, Steven Schveighoffer пишет:
> On Sun, 17 Feb 2013 19:58:06 -0500, Nick Sabalausky
> <SeeWebsiteToContactMe at semitwist.com> wrote:
>
>> On Sun, 17 Feb 2013 13:18:05 -0800
>> Walter Bright <newshound2 at digitalmars.com> 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