Orange - Free from D1/Tango

Steven Schveighoffer schveiguy at yahoo.com
Sun Feb 17 17:27:17 PST 2013


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!

-Steve


More information about the Digitalmars-d mailing list