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 { }

For those unfamiliar with Orange, it's a serialization library. More information available at github:

https://github.com/jacob-carlborg/orange

-- 
/Jacob Carlborg

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?

On 18 February 2013 07:18, Walter Bright <newshound2@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?
>

I think both are useful, but I would expect opt-in rather than opt out as Walter asserts. For instance:

@serialise class Foo // everything in the class
{
     int a;
     @noSerialise int cacheValue; // except this
}

On Sun, Feb 17, 2013 at 01:18:05PM -0800, Walter Bright 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?

I believe the purpose of the library is to provide convenient saving / loading of objects (among other things), so you want most of your data serialized, and non-serialized fields are the exception rather than the norm.  So it makes sense to serialize by default and mark out fields that shouldn't be serialized.


T

-- 
"640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.

On Sun, 17 Feb 2013 13:18:05 -0800, Walter Bright <newshound2@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?
>

Every serialization library i've used is opt-out.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Sun, 17 Feb 2013 16:18:05 -0500, Walter Bright <newshound2@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?

I would think D's type system would be capable enough where a serialization library can tell whether a type can be serialized or not.

I also think it would be a tremendous burden to put @serialized on every type that could be serialized.

When I used C#'s serializer, it was definitely annoying to have to annotate every type I wanted to serialize, and every type that was used within that type.

What is the concern with an opt-out approach?  I would think the default would be the most common option -- save everything.

-Steve

On Sunday, 17 February 2013 at 21:18:12 UTC, Walter Bright 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?

Surely not...

I shouldn't have to explicitly mark every type as allowed-to-be-serialised, it makes much more sense to opt-out.

On Sun, 17 Feb 2013 13:18:05 -0800
Walter Bright <newshound2@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.

On Sun, 17 Feb 2013 19:58:06 -0500, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Sun, 17 Feb 2013 13:18:05 -0800
> Walter Bright <newshound2@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

On Sunday, 17 February 2013 at 22:13:21 UTC, Steven Schveighoffer wrote:
> On Sun, 17 Feb 2013 16:18:05 -0500, Walter Bright <newshound2@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?
>
> I would think D's type system would be capable enough where a serialization library can tell whether a type can be serialized or not.
>

It isn't as it don't convey ownership. And hopefully as getting rid of ownership is important for idioms involving immutability.